<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 10:19 AM Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Oct 17, 2019, at 9:04 AM, Lassi Kortela <<a href="mailto:lassi@lassi.io" target="_blank">lassi@lassi.io</a>> wrote:<br>
> <br>
>> Currently Gambit’s define-library is compatible with the R7RS define-library and thus supports macros defined with syntax-rules. So this will work:<br>
>> ==> foo.scm <==<br>
>> (define-syntax hello<br>
>>   (syntax-rules ()<br>
>>     ((_) (display "Hello world\n"))))<br>
> <br>
> Ah, you explained it before but I forgot this detail. Sorry about that.<br>
> <br>
> 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.<br>
> <br>
> It's possible to do the translation using syntax-case like this:<br>
> <br>
> (symbol->keyword (syntax->datum keyword-as-ordinary-symbol))<br>
> <br>
> define-macro is also good enough if there's an easy way to export the macro.<br>
> <br>
>> 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).<br>
> <br>
> 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 :)<br>
<br>
That is currently the case… an (import foo) will look for foo.scm, and the (import foo) will expand to<br>
<br>
(##demand-module foo)<br>
(##include "/the/module’s/path/foo#.scm") ;; if that file exists<br>
<br>
> <br>
>> We would like to make the two module systems coexist more seamlessly, so any ideas on how to do that are welcome.<br>
> <br>
> 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.)<br>
<br>
Expressive power vs. interoperability with other Schemes.  All Schemes make the compromise that suits them.<br>
<br>
Marc<br>
<br>
<br>
_______________________________________________<br>
Gambit-list mailing list<br>
<a href="mailto:Gambit-list@iro.umontreal.ca" target="_blank">Gambit-list@iro.umontreal.ca</a><br>
<a href="https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list" rel="noreferrer" target="_blank">https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list</a><br>
</blockquote></div>