Thanks for continuing this old thread, Marc. John never got a proper
reply to his thoughtful comments.

>>> I like the idea of allowing arbitrary s-exps following "#!" (i.e.
>>> "#!(precision 25)" instead of "#!precision=25") so that "#!" can be
>>> parsed as datum comments "#;".
>
> I like that idea because the syntax is simple, already built into the
> reader, and leaves all options open.

I also like #!(precision 25) because wrapping one thing inside
parentheses is very Lisp-like; it's obvious which forms belong together.

John said he prefers #!precision 25. If I understood correctly, it's
because in #!x y, the #!x can affect how the y is read. In #!(x y) the y
has to be read in using the reader settings that were in effect before
the directive appears. I don't understand the implications; are there
cases where the directive should affect how it reads its own settings or
metadata? Perhaps there could be.

>> · For “#!” followed by an identifier beginning with “/”, treat the whole
>> line as a comment.

This is meant as a standard way for Scheme to ignore Unix #!/usr/bin/env
lines. While this approach is simple by one measure, it's at once more
general and more brittle than it has to be to solve the problem.

Unix #! lines are similar to encoding declarations in two ways:

1) They deviate from standard Scheme syntax.

2) They only make sense at the beginning of a file.

Hence I would recommend the following approach:

1) Open each Scheme file as a byte port initially.

2) Run it through a custom byte-based reader that scans for the Unix #!
line and the encoding declaration.

3) Once it has found those things (or read N bytes without finding
them), re-read the file from the beginning as a textual port with the
right encoding.

4) Don't have any #!/bin/ or encoding directives in the normal Scheme
reader.

>> 3) Using the format “#!foo some-s-expression-depending-on-foo” allows
>> different values of foo to be registered and treated separately with
>> different rules for each, rather than aggregating them into a single
>> alist or such.
>
> What do you exactly mean?

I think the practical difference is that
`some-s-expression-depending-on-foo` can have different read syntax
depending on `foo` directive. So the read syntax can change after
reading the `#!foo`, but before reading
`some-s-expression-depending-on-foo`. This is not possible with the
`#!(foo some-s-expression-depending-on-foo)` syntax that we prefer.

If the read syntax is the same, then it's just a matter of whether the
`some-s-expression-depending-on-foo` is a nested or top-level
S-expression. I can't think of a case where that makes a difference.

> In which sense does the compiler need to be affected and what does
> phasing have to do with it?

(This part of the discussion flew over my head :)

>> 5) In particular, one directive I’d like to have eventually is “#!lang”,
>> which is followed by a module path.  The compiler/REPL dynamically
>> imports the module named in the path and uses the `read` procedure
>> exported from that module in place of its own `read`.  This allows
>> arbitrary other languages to be compiled/interpreted with any conforming
>> Scheme system.  It is similar to Racket’s “#lang”, but simpler.  (I
>> don’t like “#lang” because if we introduce “#l” for some new kind of
>> external syntax, it might be read as “#l ang”.
>
> Doesn't this contradict/overlap the argument raised in 4)? Maybe, I
> don't fully understand.

I would advise against a #!lang directive. It makes R7RS interop
difficult in Racket, as one example. Once you put #!lang at the top of a
file written in another language, you can only use a #!lang-aware
reader. If I take a Python file and put `#!lang python` on top, ordinary
Python can no longer read it. Nor do text editors and other tools
understand it. It's like those USB cables that speak standard USB but
have proprietary connectors so you can only plug them in to
Apple/Microsoft/etc. devices.

If Scheme implementations want to support non-Scheme languages, they
should work with the established customs of those communities instead of
inventing our own customs as outsiders. That's why I'd prefer to have
multi-language-support metadata in some file(s) outside the source files
themselves.