> In some code I've been working on today, I have seen something curious:
> macros which work when used in the REPL/"at the top level"-- but which given
> an error message when used with in a module.
>> The full example is rather long, but complains:
> compile: bad syntax; function application is not allowed, because no #%app
> syntax transformer is bound in: ...
After giving it some thought, I don't have any good guesses.
> In a rather stipped down version, I am still able to produce a (different)
> error when my stripped-down macro is used within a module vs. in the REPL
> (where the code works "fine"). This stripped down case is given below. When
> the define-struct/prop macro is used within a module, the error message given
> is:
> module: identifier originates in a different module in: acc
Arguably, this is a bug in compiling for the top level. Like a module
body, the top level really shouldn't allow a definition where the
defined name has a foreign module context. Currently it does, though.
Why? Due to the import of MzScheme's syntax into the top-level
environment, the `lambda' in
(define-syntax lambda ....)
will get the `mzscheme' module context. So, rejecting module-contexted
definitions at the top-level would prevent certain definitions that are
currently allowed. Compared to modules, the difference is that multiple
top-level definitions are often considered ok (and the last one takes
over).
I can never remember whether definitions like the one above are
actually permitted by R5RS. But it's the sort of thing many
implementations try to allow, and it can be handy in REPL-style
debugging.
Matthew