Not sure if this is related what Marc wrote, but this is not even close to
what I'm proposing. My syntax extension is like combination of reader and
compiler macros in Common Lisp, but in CL - reader macro have access to stream
of characters, in my extension they get the parsed expression.

I'm not sure how CL reader macros works with packages, they probably
just helpers for user code. One thing to fix the issue with Libraries is that
the syntax may disallow of writing set-special! inside bigger expression that
will invalidate it in libraries. So they will only be used by user code
as helpers for the application and not in libraries. Or just invalidate it or
ignore if inside libraries. So it don't break the Scheme code too much with
this restriction.

On Sun, 14 Mar 2021 22:54:26 -0400
John Cowan <xxxxxx@ccil.org> wrote:

> See https://github.com/johnwcowan/r7rs-work/blob/master/LexmacsCowan.md,
> which is a proposal that's close to what you are describing.
>
> On Mon, Mar 8, 2021 at 3:25 AM Marc Nieper-Wißkirchen <
> xxxxxx@nieper-wisskirchen.de> wrote:
>
> > A possible R[67]RS way compatible with modularization would be to first
> > specify how the `read` procedure can be extended (not globally but
> > customized in the object-oriented inheritance sense) and then specify how
> > files are associated to (custom) `read` procedures. The latter may yet
> > have to be left implementation-specific. It's important that (new) reader
> > syntax applies globally to a stream and doesn't change in the middle of a
> > stream (possibly in the middle of a datum).
> >
> > Am Mo., 8. März 2021 um 08:48 Uhr schrieb Jakub T. Jankiewicz <
> > xxxxxx@onet.pl>:
> >
> >> Thanks for your comment about my feature, I think that I will not work on
> >> this
> >> further to make it SRFI then. You're right it don't work correctly with
> >> the
> >> libraries because R7RS Scheme is not longer single global namespace, so
> >> single global syntax extensions would be problematic.
> >>
> >> Jakub
> >>
> >> On Sun, 7 Mar 2021 23:07:43 +0100
> >> Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
> >>
> >> > PS: I want to add that I am not principally opposed to ways to extend
> >> the
> >> > Scheme reader. The difficulty is to make this work in conjunction with
> >> >
> >> the
> >> > library system and the usual Scheme semantics and so that special
> >> > syntax loaded for one file does not affect other files.
> >> >
> >> > Am Sa., 6. März 2021 um 17:19 Uhr schrieb Marc Nieper-Wißkirchen <
> >> > xxxxxx@nieper-wisskirchen.de>:
> >> >
> >> > > Am Sa., 6. März 2021 um 17:03 Uhr schrieb Jakub T. Jankiewicz <
> >> > > xxxxxx@onet.pl>:
> >> > >
> >> > >>
> >> > >>
> >> > >> On Sat, 6 Mar 2021 15:43:01 +0100
> >> > >> Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
> >> > >>
> >> > >> > > We can simplify the SRFI by requiring for implementation to
> >> > >> > > work
> >> in
> >> > >> > > different
> >> > >> > > files. This is how it was working before I replaced tokenizer
> >> > >> > > in
> >> my
> >> > >> Scheme
> >> > >> > > that return list of all tokens for whole file with incremental
> >> Lexer
> >> > >> > >
> >> > >> that
> >> > >> > > is
> >> > >> > > tokenizing while the code is parsed.
> >> > >> > >
> >> > >> >
> >> > >> > How would this look like in a typical R7RS Scheme program
> >> consisting
> >> > >> > of
> >> > >> a
> >> > >> > top-level program and a number of libraries?
> >> > >> >
> >> > >> > What happens if two libraries try to declare the same prefix
> >> > >> independently
> >> > >> > as special?
> >> > >>
> >> > >> The specials are global because the parser is single entity. But
> >> > >> what about
> >> > >> SRFI-10 if two libraries define same name (e.g. #,(foo ...)) and
> >> they use
> >> > >> different implementations. From what I see SRFI-10 don't use any
> >> scope
> >> > >> and don't handle the R7RS libraries. The latest library will
> >> overwrite
> >> > >> the code
> >> > >> that was defined in libraries that were loaded before it if both
> >> defined
> >> > >> the
> >> > >> name.
> >> > >>
> >> > >
> >> > > Yes, any SRFIs that define reader extensions usually define them
> >> globally.
> >> > > For (quasi) standards, this is less of a problem than for
> >> > > user-written extensions which need to co-exist with other
> >> > > user-written extensions.
> >> > >
> >> > > For example, assume that I want to use a library (foo). The
> >> implementor of
> >> > > (foo) uses some other library (bar), which makes use of your proposed
> >> > > reader extensions, internally. If the reader extensions are only
> >> global,
> >> > > (foo) will leak implementation details.
> >> > >
> >> > > SRFI 10, by the way, is both pre-R6RS and pre-R7RS so it is clear
> >> that it
> >> > > doesn't handle libraries. Moreover, I would consider the special
> >> syntax
> >> > > used there and the SRFI itself obsolete because since R6RS, `#,` is
> >> > > an abbreviation for `unsyntax`.
> >> > >
> >> > >
> >>
> >> --
> >> Jakub T. Jankiewicz, Web Developer
> >> https://jcubic.pl/me
> >>
> >

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