Re: [Scheme-reports] (dynamic) lexical extensions John Cowan (11 May 2012 04:37 UTC)
Re: [Scheme-reports] (dynamic) lexical extensions Daniel Villeneuve (12 May 2012 02:53 UTC)
Re: [Scheme-reports] (dynamic) lexical extensions John Cowan (12 May 2012 05:07 UTC)

Re: [Scheme-reports] (dynamic) lexical extensions John Cowan 11 May 2012 04:37 UTC

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

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

No.

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

Comments?

--
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@ccil.org
internal links in forms which are hideously
over-complex. --Simon St. Laurent on xml-dev

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