Syntax extensions Jakub T. Jankiewicz (05 Mar 2021 20:44 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (06 Mar 2021 09:10 UTC)
Re: Syntax extensions Amirouche Boubekki (06 Mar 2021 09:23 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (06 Mar 2021 14:26 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (06 Mar 2021 14:43 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (06 Mar 2021 16:03 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (06 Mar 2021 16:20 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (07 Mar 2021 22:08 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (08 Mar 2021 07:47 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (08 Mar 2021 08:25 UTC)
Re: Syntax extensions John Cowan (15 Mar 2021 02:54 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (15 Mar 2021 08:01 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (15 Mar 2021 15:53 UTC)
Re: Syntax extensions Adam Nelson (16 Mar 2021 12:07 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (16 Mar 2021 12:50 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (16 Mar 2021 16:37 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (16 Mar 2021 17:12 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (16 Mar 2021 17:31 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (16 Mar 2021 19:53 UTC)
Re: Syntax extensions John Cowan (18 Mar 2021 20:10 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (18 Mar 2021 21:36 UTC)
Re: Syntax extensions John Cowan (19 Mar 2021 04:18 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (19 Mar 2021 06:43 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (19 Mar 2021 08:04 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (19 Mar 2021 08:12 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (15 Mar 2021 15:42 UTC)
Re: Syntax extensions John Cowan (18 Mar 2021 00:38 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (18 Mar 2021 06:36 UTC)
Re: Syntax extensions Amirouche Boubekki (06 Mar 2021 09:47 UTC)
Re: Syntax extensions Jakub T. Jankiewicz (20 Aug 2021 21:03 UTC)
Re: Syntax extensions Marc Nieper-Wißkirchen (20 Aug 2021 21:18 UTC)

Re: Syntax extensions Jakub T. Jankiewicz 16 Mar 2021 17:31 UTC


On Tue, 16 Mar 2021 18:12:28 +0100
Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

> Am Di., 16. März 2021 um 17:37 Uhr schrieb Jakub T. Jankiewicz <
> xxxxxx@onet.pl>:
>
> > Now this is becoming interesting and something closer to what I have in
> > mind. what this approach:
> >
> > #!(import (reader expandable))
> >
> > and now the reader is in mode that allow to use syntax extension. So it
> > would
> > be two steps process. First you load the reader that is capable of
> > extending.
> > and then you have some other syntax that allow to add new syntax.
> >
> > In case of my implementation it's set-special! but it can be any other
> > syntax
> > that map string into a function (on implementation also support few
> > different
> > things but I think that you can do everything it needs to be done with
> > just functions that are like FEXPR or compiler macros that return atom of
> > list).
> >
> > So the code would be:
> >
> > #!/usr/bin/env scheme-script
> > #!(import (reader expandable))
> >
> > (set-special! "#:" 'keyword)
> >
>
> This is actually an *application* of what I had in mind.
>
> Of course, your "(reader expandable)" can interpret "set-special!", etc.,
> and you could do it with the approach I have in my, but what I envision
> means to load a reader through "#!(import ...)" that already comes with all
> customizations.
>
> To illustrate, "(my reader)" could be defined by (R6RS syntax, for a
> change):
>
> (library (my reader)
>   (export reader)
>   (import (reader expandable)
>           ...)
>   (define reader (make-expandable-reader))
>   (define keyword ...)
>   (set-special! reader "#:" keyword))
>
> Here, "set-special!" would only affect a reader object and not the parsing.
> It comes into play here:
>
> #!(import (my reader))
> #:key

I like this idea. This would solve lot of complication with modification of
the parser while it's running, because #! can be read before the file is
parsed. With my Scheme based lisp I have incremental lexer/parser/evaluator
because this is now it was implemented. But expecting other Scheme
implementation to do the same is not very good idea, because probably no one
will implement the feature.

This eliminate the problem of:

(set-special! "#:" 'keyword)
#:key

I wander how this would work with dynamic REPL. Do you think that there
should be a way to use new syntax set-special! in REPL to define new syntax.
I think that there should be a way to change the reader in REPL so this is
possible. Also with REPL since each evaluation is parsed separately there is
no reason not to allow to use set-special! outside of library.

>
>
> > I was also asking about Reader macros in Common Lisp by the person that
> > was answered my old question on StackOverflow and it seems that common
> > lisp have
> > single global variable for the reader, and it don't give any issues.
> >
>
> Sure, one can program with a lot of global variables but this doesn't make
> it state-of-the-art. :)
>
> Some warts of global state are still left, notably in SRFI 128 (the
> comparator registry), but no one has yet found a good way to get rid of it.
> For our goals here, however, global state (by which I mean state across
> libraries) is unnecessary as the above proposal shows.

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