Am Mo., 20. Mai 2019 um 11:21 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > 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.

>
> John hasn't had the chance to post to srfi-discuss but sent detailed
> comments about the #! proposal. Here they are verbatim:
>
> ----------------------------------------------------------------------
>
> 1) I would like to stick to the pattern “#!foo” where “foo” is any valid
> Scheme identifier.
>
> 2) Depending on the value of foo, the reader may take specific action:
>
> · For “#!encoding”, read the next S-expression (which must be a symbol),
> set the encoding, and either rewind (skipping the encoding this time) or
> carry on if you can change encodings in midstream (lots of systems cannot).

The alternative would be, say, #!(encoding latin1). Is it worse than
#!encoding latin1? Apart from that, do we really need such a
directive?

>
> · For “#!fold-case” and “#!no-fold-case”, read nothing and set the
> port’s case-folding flag;
>
> · For “#!r6rs” (in R6RS systems), read nothing and set the port’s
> strict-R6RS mode if the implementation has one (Larceny does, Guile
> doesn’t);
>
> · For “#!” followed by an identifier beginning with “/”, treat the whole
> line as a comment.

It would be enough to have this behavior at the very beginning of a file.

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

>
> 4) Having a procedure to set the interpretation of “#!foo” for a
> specific “foo” is fine if all you want to do is affect the `read`
> procedure.  But if you want to affect the compiler, you have to have a
> way to run that code *in the compiler*.  Scheme has never messed about
> with `eval-when`, and for very good reason.  (This issue also affects
> SRFI 10, and is exactly analogous to the phasing problem in R6RS.)  So I
> am in favor of standardizing new #!foo directives only by SRFI.  I have
> an alternative approach from SRFI 10 in pre-SRFI form at
> <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/LexmacsCowan.md>.

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

Do you mean using the reader as part of the process of expanding and
executing a Scheme program vs. using the reader through the `read'
procedure?

I agree that this needs some thinking and some specification. However,
I don't think that it cannot be done. The R6RS macro system is sound
and phasing issues are mostly transparent or irrelevant to the user
when the implementation follows the implicit phasing model. (I
wouldn't propose the optional explicit phasing in the R6RS.)

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

Marc