Our implementation uses a lexical analyzer that can be rebuilt
on-the-fly.  We take advantage of this to extend the syntax as code is
read, outside of the core Scheme interpreter.  For instance, we can write

(reader-push-date!)

in a scheme file and this function will push a date regex and a
corresponding handler on the lexical analyzer stack, which will be
rebuilt reactively after the right parenthesis.  Afterwards, dates can
be read "natively".

Other examples include (reader-push-time!) and (reader-push-xml!), the
latter allowing to parse inline XML data as SXML by recognizing the
special sequence <?xml (which is no longer a valid symbol) and call an
XML parser to read up to the termination of the main element.

However, this seems at odds with the case-folding variants proposed in
R7RS (#![no-]fold-case and include-ci).

Imagine having n orthogonal syntactic variants, would we end up with 2^n
include forms?

Should we be able to pass syntax variant options to open-input-port, or
be able to modify (current-input-port), to control the lexer/reader when
reading data files or interactive ports?

More generally, is the syntax variant mechanism proposed by R7RS meant
to be the basis for more lexical extensions (both when reading code at
compile time and when using read at runtime on data)?
--
Daniel Villeneuve
AD OPT, a Kronos Division

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports