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