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

John Cowan cowan at ccil.org
Thu Oct 17 14:12:08 EDT 2019

Has the syntax-case module for Gambit bit-rotted?  I know it had
trouble interacting with DSSSL lambda-list keywords, but I doubt if it
blocks the ordinary kind.

Define-macro is TRULY EVIL and shouldn't be used anywhere you don't
absolutely have to, even where it is available.  As far as I know, the only
other Schemes that have both keyword objects and lack another low-level
macro system besides define-macro are S7 and STKlos, neither of which are
particularly popular today.

On Thu, Oct 17, 2019 at 10:19 AM Marc Feeley <feeley at iro.umontreal.ca>

> > 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.
> Marc
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20191017/32bb82d4/attachment.htm>

More information about the Gambit-list mailing list