[The following discussion between Marc N-W and me was accidentally sent
off-list. My comments are the quoted ones.]

> The survey at https://registry.scheme.org/#hash-bang-syntax lists #!
> being used for 3 kinds of things:
>
> - directives: #!r6rs #!nocache
>
> - objects: #!eof #!bwp #!null -- just like a self-evaluating datum
>
> - keywords: #!key #!optional #!rest -- like a datum but may not be a
> free-standing object that is allowed everywhere objects are allowed

Thanks for the survey. While all of these tokens may have different
purposes, their common feature is that they affect the reading process.

> Of the above, #!nocache is a good example of something that doesn't
> affect RnRS semantics but has important systems implications.
>
> A further problem is that Scheme readers should not ignore unknown
> #!directives. So reading a file with #!nocache into an implementation
> other than Sagittarius will fail. This suggests that #!directives are
> not an ideal place to put hints about caching.

An R6RS scheme mustn't even ignore any such extensions to the lexical
syntax after it has seen "#!r6rs"-

> What about directives that are meant for Scheme, but that can be ignored
> without affecting RnRS, like #!nocache. We could use "#! nocache" with a
> space, i.e. the same syntax as 220 proposes for external declarations.
> Does that make sense? In this case it doesn't matter whether string of
> datum syntax is used.

For compatibility to R6RS (until it is replaced by a successor), such
directives would have to be placed in ordinary comments.

> If we want "#! " and also have to keep RnRS's existing "#!" then we need
> to distinguish between intertoken space and no intertoken space. That's
> not as neat as I'd like, but given the precedent or Unix "#!" we don't
> have many alternatives.

Precisely not. :)

-- Marc

> Any directive syntax that supports external tools has to content with
> the Unix prior art of "#! /usr/bin/env foo". The only prefix that works
> with that is "#!". We could detect "#!/" (no space) but then we can't
> subsume the myriad other stuff like "SPDX-License-Idetifier" into the
> same system. If we look for "#! " (with whitespace) we can.

The shebang can (and should be) left out of the discussion. (Also note
that SRFI 22 prescribes a space after it.) It can only appear as a magic
file prefix. It should never be passed to the reader proper. The Scheme
interpreter that opens a file for running should check for the shebang
line and remove it before the rest is read as a program. If I open a
program file containing a shebang line at the beginning with, say,
call-with-input-file, and use read on the resulting port, I would expect
a reader error (unless some "#! " syntax is implemented).

So, conceptually, we have a "loader" before the reader when executing
Scheme scripts. The loader just strips a magic line.

> This is true as long as we don't have "#! " (shebang followed by a
> space) read syntax. If we have that particular syntax for comment-like
> directives, then the shebang can and should be treated as one of those
> directives. The reader can supply line and column numbers to the handler
> procedure so it can check whether it's looking at the start of the file.

I'm not convinced that the shebang "should" be treated as one of those
directives (if they are implemented).  A Scheme script with a shebang is
not a file containing Scheme datums but a file containing a shebang line
followed by external representations of Scheme datums. (This is also
clearly spelled out by the non-normative Appendix D of the R6RS: The
shebang line is not part of a top-level program, which is fed to the
reader.)

Anyway, the shebang should not influence at all the design of embedding
meta-information à la SRFI 220. Both the format of what follows "#!" and
even the exact character sequence to be used (currently "#!") needn't
and should not be dictated by the shebang.

To conclude:

For the original purpose of SRFI 220 (line-oriented embedded data like
license information or editor-specific settings), it is, therefore,
adequate to re-use the line comment syntax of Scheme, namely ";".  SRFI
220 can define a magic character so that line comments beginning with
such a character are understood to be machine-readable, e.g. ";*
License: GPL-3.0".  This has the following big advantages:

(1) It is compatible with all Schemes in existence.
(2) The ";*" directives are naturally limited by line endings as most
external tools would expect.
(3) There is nothing like embedded comments, nested comments, or
multi-line recursive data structures in ";" comment lines, making
parsing for external tools much easier.
(4) There won't be any interdependencies with the existing use of the
"#!" characters, which prefix reader directives.