Re: Properly phased lexical syntax extension, read-time evaluation, and HashDot Scheme Jakub T. Jankiewicz (04 Apr 2021 08:02 UTC)

Re: Properly phased lexical syntax extension, read-time evaluation, and HashDot Scheme Jakub T. Jankiewicz 04 Apr 2021 08:02 UTC


On Sat, 3 Apr 2021 22:26:29 -0400
John Cowan <xxxxxx@ccil.org> wrote:

> On Fri, Apr 2, 2021 at 3:30 AM Marc Nieper-Wißkirchen <
> xxxxxx@nieper-wisskirchen.de> wrote:
>
> My thesis is that we never want incremental extensions to existing syntaxes
> > (unless we are submitting a contribution to an obfuscated code contest).
> > We want global and maybe local extensions (where a global extension can be
> > seen as a local one encompassing the whole source file).
> >
>
> I don't think we are talking about the same thing.  #lang provides a
> completely separate reader unrelated to any other reader, whereas I am
> talking about something that adds lexical syntaxes to the Scheme reader (or
> any other reader, in principle).
>
> For example, when we import SRFI 160 homogeneous vectors, we would want to
> also make the associated lexical syntax like #s8, #s16 etc. available both
> for source code and for data files.  Either of these could be global or
> per-file.  I call this type "incremental" because it extends the standard
> syntax with new features; it does not normally redefine existing features.
>
> It's true that given #. you don't actually need this: you can write
> #.(make-s8vector 1 2 3 4).  However, this makes bombs more likely.  It's
> for this reason that SRFI 10 hash-comma, which is closely related, doesn't
> accept arbitrary expressions in the pseudo-function position, but
> well-known identifiers meaningful only to it.  (You can extend them at run
> time, but not at load time.)

This is also exactly what I have in mind when I first read this. Changing the
reader so it allow new syntax like #u16 if the default reader don't support
it yet. I'm fine with solution of dealing with libraries and have something
like Racket #lang or #reader at the beginning of the file, because if I want
what I was originally wanted, to modify the reader directly int the file, I
can possible write my own reader that will allow to use same syntax as I have
in my Scheme based interpreter:

#reader (reader lips-reader)

(set-special! "#u16" 'u16-vector)
#u16(1 2 3)

And the reader can be some Reader that allow extension or just something
like:

#reader (scheme scheme-next)

where scheme-next is reader that implement every single SRFI and everything
that R7RS have.

What nice about this is that the reader can be library, written in compatible
way, so it could be run in every scheme implementation that support changing
readers.

So to have proper proposal I think that I don't need to extend the parser
with new syntax anymore, because I can just write library that will do that.
We only need a way to change the reader at file load time. There will probably
need to be a way to do the same in REPL, for executable it's not a problem
because you can add option to change the reader

scheme --reader "(scheme scheme-next)"

But with something like try Scheme Web App it may be not possible. Maybe REPL
should have #reader syntax as well, because REPL is also single entity
initialized only once, the same as running scheme from file.

--
Jakub T. Jankiewicz, Web Developer
https://jcubic.pl/me