[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] (dynamic) lexical extensions

Daniel Villeneuve scripsit:

> 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.                    

Scheme implementations often provide such facilities in the form of
a Common Lisp readtable or otherwise, but no Scheme standard has ever
provided user-mutable syntax.  SRFI 10 has a special case of mutable
syntax: a form like #,(foo bar ...) invokes a procedure bound to foo,
passes it bar and other arguments, and reads as whatever the procedure

All such systems have phasing problems analogous to those created by
low-level macros, only worse.  They are hard to provide in compiler
systems that read a whole library S-expression; when do you execute the
code that redefines the reader?  A highly dynamic interpreter can handle
such things, but not all implementations are like that.

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

They are primarily for backward compatibility, to allow processing data
and code files respectively that exploit case-folding.

> 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)?


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

Indeed we would.

> 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?

That's what would be required.  I'm not convinced that it would be
either necessary or sufficient.


Here's an idea I've been kicking around, though: to generalize
quasiquote, which is a lexical syntax that generates a prescribed
syntax form.  For example, `#foo 32` could be rewritten as (lexical-foo 32).
It's then up to you to define a macro named lexical-foo, about which the
reader knows nothing, just as it knows nothing about the standard macro
`quasiquote`.  This would only work in code; to make something similar
work for data, you'd need to walk the result returned by `read`.


No,  John.  I want formats that are actually       John Cowan
useful, rather than over-featured megaliths that   http://www.ccil.org/~cowan
address all questions by piling on ridiculous      cowan@x
internal links in forms which are hideously
over-complex. --Simon St. Laurent on xml-dev

Scheme-reports mailing list