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