Marc:
Assume that there's a file called "streams.scm" that has Phil Bewig's streams code in it, and that there's a file called "sieve.scm" that uses the definitions in streams.scm
Now, when I do
[Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6
(load "streams.scm")
"/Users/lucier/Downloads/streams.scm"
(load "sieve.scm")
"/Users/lucier/Downloads/sieve.scm"
(stream->list 10 primes)
(2 3 5 7 11 13 17 19 23 29)
everything works fine. But if I compile the streams code and do
[Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6
(load "streams")
"/Users/lucier/Downloads/streams.o3"
(load "sieve.scm")
*** ERROR IN #<procedure #2>, "sieve.scm"@5.6 -- Unbound variable: define-stream
then, as you can see, a macro from streams.o3 is not available for use in expanding sieve.scm.
So, I guess I don't understand the "persistence" or whatever you would call it of R5RS macros, and how that interacts with Gambit's compilation model.
Can you help?
Brad
Afficher les réponses par date
One other data point, where things work fine:
[Media-Mac-mini-3:~/Downloads] lucier% gsc -:s Gambit v4.6.6
(load "streams.scm")
"/Users/lucier/Downloads/streams.scm"
(compile-file "sieve.scm")
"/Users/lucier/Downloads/sieve.o4"
(load "streams")
"/Users/lucier/Downloads/streams.o3"
(load "sieve")
"/Users/lucier/Downloads/sieve.o4"
(stream->list 10 primes)
(2 3 5 7 11 13 17 19 23 29)
I don't have access to your code, but it looks like you have a phasing problem. 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.
Marc
On 2013-01-31, at 1:38 PM, Bradley Lucier lucier@math.purdue.edu wrote:
Marc:
Assume that there's a file called "streams.scm" that has Phil Bewig's streams code in it, and that there's a file called "sieve.scm" that uses the definitions in streams.scm
Now, when I do
[Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6
(load "streams.scm")
"/Users/lucier/Downloads/streams.scm"
(load "sieve.scm")
"/Users/lucier/Downloads/sieve.scm"
(stream->list 10 primes)
(2 3 5 7 11 13 17 19 23 29)
everything works fine. But if I compile the streams code and do
[Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6
(load "streams")
"/Users/lucier/Downloads/streams.o3"
(load "sieve.scm")
*** ERROR IN #<procedure #2>, "sieve.scm"@5.6 -- Unbound variable: define-stream
then, as you can see, a macro from streams.o3 is not available for use in expanding sieve.scm.
So, I guess I don't understand the "persistence" or whatever you would call it of R5RS macros, and how that interacts with Gambit's compilation model.
Can you help?
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
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.
Brad
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
On Jan 31, 2013 2:35 PM, "Bradley Lucier" lucier@math.purdue.edu wrote:
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.
Macros have file scope in compiled code.
I'm not sure on the details, but if I were to guess I'd say that the compiler macro-expands and then compiles, not bothering to write the macro definitions into the compiled module; whereas if you `load' scheme source, it's like you typed each expression singly at the REPL, and those macro definitions become available.
In general, for gambit it's not safe to assume your macro definitions will be visible outside the file they were defined in.