PPS We should also keep in mind that R6RS libraries may not reside in
files, so that (relative) file paths can be pretty meaningless during
expansion.

Include, in the form of R7RS library-level include, should be seen as
an element of the build environment, IMO. (This also fits the view
that R7RS's define-library is a recipe for how to generate an R6RS
library from fragments residing on the file system.,

Am So., 3. Aug. 2025 um 15:17 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> PS In case there is interest, I can write a SRFI around read-syntax/get-syntax.
>
> Am Fr., 1. Aug. 2025 um 20:52 Uhr schrieb Marc Nieper-Wißkirchen
> <xxxxxx@gmail.com>:
> >
> > I agree with what John said.
> >
> > Moreover, while "define-values" seems to be uncontroversial, getting
> > "include" right (and not too underspecified) is hard. Racket tries to
> > get it right, but has to offer different versions.
> >
> > Any version of include can be implemented using the R6RS procedural
> > macro system, so any package that thinks it needs it can ship a
> > suitable implementation right now.
> >
> > What I would find much more important than "include" and far less
> > controversial would be a "read-syntax" or "get-syntax" procedure that
> > works like a combination of datum->syntax and read (or get-datum), but
> > may fill in source-location information. Having this, everyone would
> > be able to write a feature-complete include.
> >
> > Marc
> >
> > PS The include form that would be specified by a SRFI would be like
> > the R7RS form that is allowed to appear in programs and libraries but
> > not in library headers. However, this has never seen much use; library
> > header-include (which is different from it and which doesn't apply to
> > R6RS) is what is used.
> >
> > Am Fr., 1. Aug. 2025 um 15:09 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> > >
> > > I believe the objection would be that it makes it impossible to assign a fixed semantics to an R6RS program or library, because the meaning of the argument is system-dependent, and more than that, what is included depends on the current state of the filesystem. A  library with `include` is not a library but a recipe for constructing one.
> > >
> > > I believe this objection could be met by defining a C-style preprocessor, of course based on S-expressions rather than lines of text. That's assuming that anyone cares about such a feature.
> > >
> > > On Fri, Aug 1, 2025, 5:45 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
> > >>
> > >> Would there be interest in a SRFI which provided the R7RS ‘include’ syntax to R6RS programs?
> > >>
> > >> Precedent would be SRFI 244, which exists for no other reason than to provide the R7RS ‘define-values’ syntax to R6RS programs.
> > >>
> > >>
> > >> Daphne
> > >>