Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Scheme Programming Language

Is this problem solved in scheme?


hi

After coding the Groebner Basis program in scheme, I have a good
question to ask. I have coded the low level polynomial library with
excessive error catch statements, now after the code has being semi-
proved working, how do I systematically remove those dead code? "Dead
code" in the sense that when called from some particular top level
functions those exceptional situations can never happen. There is no
way I am going to it by eye-balling the codes. Is this problem easily
solvable in scheme using some paradigm? I sorta know this problem has
solution but probably require some brute force approach. The reason I
know there is a solution was because, I used to write verilog code for
hardware logic, and those hardware compilers can so aggressively
optimize your code that there can be no "dead code" or "un-used" path
in the final hardware logic. Thanks for sharing your insight.

narutocan@yahoo.ca writes:
> After coding the Groebner Basis program in scheme, I have a good
> question to ask. I have coded the low level polynomial library with
> excessive error catch statements, now after the code has being semi-
> proved working, how do I systematically remove those dead code? "Dead
> code" in the sense that when called from some particular top level
> functions those exceptional situations can never happen. There is no
> way I am going to it by eye-balling the codes. Is this problem easily
> solvable in scheme using some paradigm? I sorta know this problem has
> solution but probably require some brute force approach. The reason I
> know there is a solution was because, I used to write verilog code for
> hardware logic, and those hardware compilers can so aggressively
> optimize your code that there can be no "dead code" or "un-used" path
> in the final hardware logic. Thanks for sharing your insight.

One way would be to redefine these operators as macros expanding only
as the main body.

--
__Pascal Bourguignon__                     http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.

On May 7, 7:46 am, Pascal Bourguignon <p@informatimago.com> wrote:

I don't quite understand. Macro are expanded at runtime right?
Wouldn't that be the same as running the code?
My understand of macros are that macros work like feeding the code
back to the reader at run-time. (The way I imagine it works, probably
not true in reality)
If what you say is true, wouldn't math people write proofs in macros,
then expand to see if some code is actually eliminated to prove some
statements.
Can you give an small example of such technique. Thanks.

No.  They are expanded at macro-expansion time, that is, when you use
a compiler, at compilation-time.

> Wouldn't that be the same as running the code?

No.

> My understand of macros are that macros work like feeding the code
> back to the reader at run-time. (The way I imagine it works, probably
> not true in reality)
> If what you say is true, wouldn't math people write proofs in macros,
> then expand to see if some code is actually eliminated to prove some
> statements.

Well macros are just functions, so they can write directly proofs in
functions and watch the results of their functions.

The difference between macro and function is that macros are functions
that takes a form and return a form, and that are defined in a special
way, to be pluggable into the compiler.  Macros are compiler plug-in
functions.

> Can you give an small example of such technique. Thanks.

Well, I'm not too knowledgeable of scheme (I basically only know some
of R5RS), and any error catching operator would be an implementation
specific extension, so I'll take as an example
common-lisp:handler-case :

(handler-case
   (+ (/ x y) (/ (x (- y x))))
 (division-by-zero ()    (princ "Cannot divide by 0"))
 (error            (err) (princ "Got some other error: ")(princ err)))

So we could override the definition of the handler-case operator with
a macro that generates merely the protected body, that is in the above
example:  (+ (/ x y) (/ (x (- y x)))):

(define-syntax handler-case (syntax-rules ()
                               ((handler-case body handling-clause ...)
                                   body)))

--
__Pascal Bourguignon__                     http://www.informatimago.com/

"Logiciels libres : nourris au code source sans farine animale."

On May 7, 7:38 pm, Pascal Bourguignon <p@informatimago.com> wrote:

Ok, I get this. This is like using #ifdef to block out debugging code.
Ok, this would work. Actually I was hoping (or dreaming rather)
something even more magical like some magical macro-expander can
actually show me the expanded code or prove by itself some code will
never be needed and automatically not expand it at all. I guess this
is asking too much. So, the lession is I should have written the code
with some sort of #ifdef to begin with, instead of trying to eliminate
debugging code later on. Thanks.

narutocan@yahoo.ca writes:
> [...]
> Ok, I get this. This is like using #ifdef to block out debugging code.
> Ok, this would work. Actually I was hoping (or dreaming rather)
> something even more magical like some magical macro-expander can
> actually show me the expanded code or prove by itself some code will
> never be needed and automatically not expand it at all. I guess this
> is asking too much. So, the lession is I should have written the code
> with some sort of #ifdef to begin with, instead of trying to eliminate
> debugging code later on. Thanks.

Well a "good" compiler would remove dead-code anyways, so each macro
doesn't need to do it.  The only side effect is that you get a lot of
warnings about dead-code deletions...

--
__Pascal Bourguignon__                     http://www.informatimago.com/

IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.

narutocan@yahoo.ca wrote:
> Ok, I get this. This is like using #ifdef to block out debugging code.
> Ok, this would work. Actually I was hoping (or dreaming rather)
> something even more magical like some magical macro-expander can
> actually show me the expanded code or prove by itself some code will
> never be needed and automatically not expand it at all. I guess this
> is asking too much.

It may not be a practical answer in this case, but "magical expanders"
like this do exist, called partial evaluators.  Google for "scheme
partial evaluator", particularly Similix, PGG, and Schism.

A partial evaluator will let you provide partial input to a program, and
"run" it, producing a residual program that, among other things, will
omit any detectable dead code.  Partial input might just be the value of
a debug flag, for example, but if the program contains unconditionally
dead code, running a partial evaluator on it with no input should also work.

The catch is that the existing partial evaluators for Scheme aren't
exactly point-and-shoot, and you can run into issues like whether the
partial evaluator supports the Scheme dialect you're using, so you may
e.g. have to run it on a macro-expanded or otherwise stripped down
version of your code.

So while it's not asking too much to have the feature exist, right now
it might be asking too much to have be very convenient.  One reason for
this is perhaps that good compilers eliminate dead code during
compilation anyway, so it's not strictly necessary (although that's not
entirely true, since code is for humans too).

Anyway, in a case like this one, you're probably right that:

> So, the lession is I should have written the code
> with some sort of #ifdef to begin with, instead of trying to eliminate
> debugging code later on. Thanks.

There are some assert macros floating around that you might find useful,
e.g.: http://okmij.org/ftp/Scheme/util.html#assert

Anton

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc