On 2013-01-31, at 2:34 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On Jan 31, 2013, at 2:25 PM, Marc Feeley wrote:
I don't have access to your code, but it looks like you have a phasing problem.
Here's the code.
The macro definition needs to be available when code that uses the macro is compiled (because the macro's body needs to be executed to perform the code transformation). What I usually do in such cases is to split the source code in two parts "streams#.scm" which contains the macro definitions and "streams.scm" which contains the rest of the code (function definitions). Then the file "sieve.scm" should *include* the file "streams#.scm". That way, the files "streams.scm" and "sieve.scm" can be compiled separately. I'm sure you will notice the similarity with the C model (which separates ".h" and ".c" files).
Please check examples/distr-comp and specifically "dc.scm" and "dc#.scm" for an example.
I understand what you're saying, I understand your coding style.
What I don't understand is why, if I load the source (*.scm) of the macros into the REPL of gsc, the macros are available to expand the source of later files during compilation, while if I load the compiled (*.o*) versions of the same file into the REPL of gsc, those macros are *not* available to expand the source of later files during compilation. (I think I gave sufficient examples to illustrate this in my previous e-mail.
In Gambit, macros defined with define-macro are local to the file they appear in. However, macros defined with define-syntax are added to the interaction environment, which is inherited by compilations started from the REPL (such as your call to compile-file). With define-macro, you would also get this inheritance if at the REPL you *included* the streams.scm file.
Marc