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.
1) Open each Scheme file as a byte port initially.
[...]
That's basically what my XML encoding sniffer algorithm does.
> 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 :)
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.
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. 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.
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.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThe present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913)