[gambit-list] "unbound variable" after importing macro from library

Marc Feeley feeley at iro.umontreal.ca
Thu Oct 17 10:19:31 EDT 2019

> On Oct 17, 2019, at 9:04 AM, Lassi Kortela <lassi at lassi.io> wrote:
>> Currently Gambit’s define-library is compatible with the R7RS define-library and thus supports macros defined with syntax-rules. So this will work:
>> ==> foo.scm <==
>> (define-syntax hello
>>   (syntax-rules ()
>>     ((_) (display "Hello world\n"))))
> Ah, you explained it before but I forgot this detail. Sorry about that.
> The particular place this came up is SRFI 177. Unfortunately, `keyword-call` from the SRFI cannot be implemented using syntax-rules since it should translate ordinary Scheme symbols into SRFI 88 keyword objects that are compatible with Gambit's native keyword argument syntax. This would make it fully interoperable with Gambit-native keyword arguments.
> It's possible to do the translation using syntax-case like this:
> (symbol->keyword (syntax->datum keyword-as-ordinary-symbol))
> define-macro is also good enough if there's an easy way to export the macro.
>> If you want to use macros defined with define-macro, you need to put them in the file foo#.scm and use the primitive modules (i.e. foo.scm and foo#.scm files).
> The practical use case would be people doing (import (srfi 177)) and not caring how the details are implemented. So if there's some way to graft the primitive module onto the library after the fact, or for the (define-library (srfi 177)) form to say that (import (srfi 177)) should also import the primitive module, those would be perfectly fine options. Or if the primitive module can be accessed via (import (srfi 177)) without having a (define-library ...) at all. Whatever works :)

That is currently the case… an (import foo) will look for foo.scm, and the (import foo) will expand to

(##demand-module foo)
(##include "/the/module’s/path/foo#.scm") ;; if that file exists

>> We would like to make the two module systems coexist more seamlessly, so any ideas on how to do that are welcome.
> I'm sympathetic to these issues. Making different module systems co-exist is not easy. In some cases it could rule out strict standards conformance if a practical result is desired (e.g. is it conformant to export unhygienic macros from a define-library? things like that.)

Expressive power vs. interoperability with other Schemes.  All Schemes make the compromise that suits them.


More information about the Gambit-list mailing list