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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
