Scheme Programming Language :: Is this problem solved in scheme?


	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: - Hide quoted text - > 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. 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. - Hide quoted text - > -- > __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. - Hide quoted text - narutocan@yahoo.ca writes: > On May 7, 7:46 am, Pascal Bourguignon <p@informatimago.com> wrote: >> 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. > I don't quite understand. Macro are expanded at runtime right? 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: - Hide quoted text - > narutocan@yahoo.ca writes: > > On May 7, 7:46 am, Pascal Bourguignon <p@informatimago.com> wrote: > >> 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. > > I don't quite understand. Macro are expanded at runtime right? > 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))) 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. - Hide quoted text - > -- > __Pascal Bourguignon__ http://www.informatimago.com/ > "Logiciels libres : nourris au code source sans farine animale." 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