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)

and also the symbol can be a value it don't need to be symbol. But if the
keyword is the symbol it's easier to handle case like this:

(letrec ((keyword (lambda (symbol) `(quote ,(gensym symbol)))))
   (set-special! "#:" keyword))

But if you thing that this should work the set-special! can have a value
instead of symbol.

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.

Also one thing that can be required is that set-special! throw an error
(or show warning and is ignored) if custom reader is not loaded.

This can be two different SRFI first to set custom reader and second with
example reader implementation that allow to extend the syntax.

I had kind of working experimental implementation of the reader patching but
it don't handle old cases because for proper implementation you will need to
write your own Scheme parser for every edge case. That's why the new reader
should be implemented by implementation that can share the parser code.

But of course if someone want to write R reader (that under the hood is very
close to lisp) he can do that and make it as library and share with every one
else.

I'm attaching kind of working code, of course it require to run (read) since
you can modify the reader while it read the file.

Note that this is old code that is using macros (syntax-rules) for extension,
latest idea was to use function that I think is lightweight then macros but
of course the proposal can use macros since macro accept unevaluated
expressions by default.

Also I just realized one thing if this will change the reader:

#!(import (reader expandable))

than library creators can write new languages in form of reader and it will
work similar to Racket languages, which may be very cool.

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

> Am Di., 16. März 2021 um 13:07 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>
> >
> > Allowing a different lexical syntax for top-level programs than for
> > libraries doesn't sound like a good idea to me. Moreover, as I have said
> > earlier, adding lexical syntax in the middle of a stream (while parsing)
> > should be avoided because the semantics are not always clear.
> >
> > A solution could be a shebang-like-line at the beginning (!) of files that
> > tells the Scheme system where to look for definitions of the reader
> > extensions used to parse that stream, e.g.:
> >
> > #! (import (my reader))
> >
> > Here, "(my reader)" would be an ordinary Scheme library that exports a
> > fixed-named identifier, say, "reader". This reader would then be used by
> > the system to parse the stream.
> >
> > Marc
> >
> >
> > +1 to this. If we're going to add reader macros/syntax extensions to
> > Scheme at all, this is how I'd want to do it.
> >
> > An additional thought is that it could be a #! keyword, like #!syntax,
> > similar to the existing #!fold-case, etc. This would make it something
> > separate from an actual shebang line, which some Schemes support.
> >
> The existing directives like "#!fold-case" or "#!r6rs" affect the state of
> a given reader. Contrary to it, the "#! (import (my reader))" sets the
> reader. Because this should only happen at the beginning of a stream (in
> particular before it is fed into the Scheme reader!), I used a shebang-like
> syntax because it is in this regard very similar to a shebang line. Both
> types can appear at the beginning of a file:
>
> #!/usr/bin/env scheme-script
> #!(import (my reader))
> <contents that are the input to the reader>
>
> > It would be nice if these reader extensions could compose in some way,
> > rather than replacing the reader entirely. Something like "read everything
> > you recognize, then fall through to the next reader extension on the stack
> > if you encounter a form you don't understand." With the option to be a
> > more complete change if necessary. Ideally, it would be something that
> > could implement most or all of the syntax extension SRFIs, including
> > things like indentation-sensitive syntax.
> >
> The good thing here is that we have a separation of concerns here:
>
> (1) Signifying that a file is to be parsed with a specific reader.
> (2) Extending the built-in reader.
>
> The first point is solved by providing some syntax like the one I have
> proposed. (It could even be made implementation-dependent with my proposal
> as a suggestion; this would be similar to how Scheme scripts are handled in
> the R6RS, or as R7RS handles mapping from library names to actual
> implementation files.)
>
> The second point is much harder and we should focus on the semantics and
> not on the exact API first.

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