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