[R6RS] syntax-case semantics

dyb at cs.indiana.edu dyb at cs.indiana.edu
Sat Mar 18 21:15:21 EST 2006

> I have run into the problem, so I prefer SRFI 72's semantics.


> I also prefer SRFI 72's less opaque definition of a syntax object,
> because it is less mysterious and because it allows the authors
> of procedural macros to reuse more of Scheme's standard library
> without having to mess with syntax-object->datum or syntax->list.

That's something I'm unwilling to consider for the surface langauge.  If
an implementation wishes to use the less opaque representation internally
or even expose it to the programmer, however, that's fine with me.  Chez
Scheme won't, because we get a lot of milage out of the more opaque
representation, including source-object correlation, constant expansion
overhead, and the ability to handle constants (including those with shared
structure or even cycles) without copying or even traversing them.

> I don't see much problem with the hash-table implementation of
> source locations, because it should be easy to modify the macro
> expander to record that information within fully macro-expanded
> code in an implementation's preferred way, discarding the hash
> table afterwards.  There is no need for weak pointers.

Unless, of course, you consider syntax objects (particularly, identifiers)
that remain in the system indefinitely as part of macro-generated
transformers, including those that are recorded in compiled files, at
which point even a weak hash-table approach becomes messy at best.


More information about the R6RS mailing list