>> 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.
>
> The encoding declaration that we were discussing is an obvious case.  The
> less junk that has, the better for everyone.
>
> Here's another case:  #!exact, which means that all literals are read as
> exact numbers, and its counterpart #!inexact.

I don't understand how either of these makes a case for or against
directives wrapped in parentheses:

- A parenthesized #!exact would be simply #!(exact). What is the difference?

- A parenthesized #!encoding utf-8 is #!(encoding utf-8). Again, how
could this be read in differently? Both declarations just use ASCII.

Where it makes a difference would be something like #!exact 123.45
versus #!(exact 123.45). In the former case, `#!exact` would be read
first and would cause 123.45 to be read in as (exact 123.45) instead. In
the latter case, the 123.45 inside the parentheses has already been read
in by the time the `exact` directive is interpreted. But this is a
pedagogical example; nobody would actually design a mechanism like this.

>> 1) Open each Scheme file as a byte port initially.
>>
>> [...]
>
> That's basically what my XML encoding sniffer algorithm does.

As well as my S-expression-based encoding/shebang-line reader, which was
also posted some months back:
<https://github.com/lassik/scheme-encoding-declaration>. But currently
Gauche and Kawa use "coding:" comments. We decided then to not make any
decision and wait for UTF-8 market share to increase further :)

> In addition to phasing related to syntax, there is also phasing related to
> lexical syntax.  A directive that changes the lexical syntax that `read`
> parses should not have to use `read`, much less `eval` to do it's work.
> That's the problem with SRFI-10's define-reader-ctor! to change the meaning
> of #,(foo ...); it is a procedure, so it operates at run time, which is too
> late to affect the lexical syntax of the program the call appears in.

That makes sense. Is that why you prefer to avoid parenthesized
directives? Anyway, in that case the parenthesized directive is fully
read in before interpreting the directive. So it is read using the old
reader configuration, not the new one.

>> If I take a Python file and put `#!lang python` on top, ordinary
>> Python can no longer read it.
>
> While this objection is sound in the general case (won't work with Fortran,
> C, Java), it so happens that a lot of so-called scripting languages treat #
> as a comment marker:  awk, Perl, Python, bash, PHP, R, probably others.

Hah, that is true :) As the first line it's problematic, since even a
Racket script has to start with a #!/usr/bin/env racket line (in
addition to #lang) sometimes. But if # is the comment character
everywhere, that doesn't matter.

Anyway, in the general case the point stands.

> Perl, in fact, respects hash-bangs itself as a throwback to the days when
> kernels did not:  if you have a file "chicken-code.scm" that begins "#!env
> csi" and you give the command "perl chicken-code.scm", Perl will actually
> exec Chicken to interpret it.
>
> Put "#env cat" at the top of a random text file, then set the exec bit on
> it, run it, and see what happens.

Wild.

>> 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.
>
> The trouble with that is that if you specify it file-by-file it doesn't
> scale.

You can have a metadata file per directory and tie it together with
Scheme's ordinary library lookup system so you can import code written
in a non-Scheme language that the Scheme implementation can also read.
Again, I strongly believe this is the right approach and would like to
sell that idea of embracing and extending Snow-Fort's package.scm files :p