SRFI 220: Line directives Arthur A. Gleckler (09 Feb 2021 23:01 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 06:49 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 07:20 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 08:46 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 10:14 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:37 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:19 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:24 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 10:30 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 10:54 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 11:13 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:31 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 12:41 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:49 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:12 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 13:21 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 12:47 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:53 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 12:56 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 12:57 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 13:05 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 13:13 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:26 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (10 Feb 2021 12:25 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 13:36 UTC)
Re: SRFI 220: Line directives Lassi Kortela (10 Feb 2021 13:49 UTC)
Re: SRFI 220: Line directives Vladimir Nikishkin (10 Feb 2021 15:42 UTC)
Re: SRFI 220: Line directives Lassi Kortela (11 Feb 2021 10:06 UTC)
Declarations in general Lassi Kortela (11 Feb 2021 10:26 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (11 Feb 2021 12:18 UTC)
Re: SRFI 220: Line directives Lassi Kortela (11 Feb 2021 12:57 UTC)
Re: SRFI 220: Line directives Lassi Kortela (17 Feb 2021 08:23 UTC)
Re: SRFI 220: Line directives John Cowan (18 Feb 2021 03:07 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (18 Feb 2021 10:16 UTC)
Re: SRFI 220: Line directives John Cowan (18 Feb 2021 23:47 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:08 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:16 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:18 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:27 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 07:32 UTC)
Re: SRFI 220: Line directives Lassi Kortela (19 Feb 2021 07:42 UTC)
Re: SRFI 220: Line directives Marc Nieper-Wißkirchen (19 Feb 2021 08:35 UTC)
Re: SRFI 220: Line directives John Cowan (20 Feb 2021 01:11 UTC)

Re: SRFI 220: Line directives Lassi Kortela 11 Feb 2021 12:57 UTC

>     As a practical matter, we should make some kind of distinction between
>     things that affect Scheme evaluation semantics ("correctness"?) and
>     things that don't.
>
> This is actually a good reason why the "#!" should probably be kept
> separate from the "#! " syntax SRFI 220 proposes. "#!r6rs" does affect
> the reader, while "#! License: Bla" mustn't. The former is a directive
> for Scheme, the latter is meta information for tools processing the
> source code.

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

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.

Sagittarius also has #!reader=<name> which replaces the current reader
with the <name> reader, where <name> varies. Using a=b syntax implies
that there's already demand for adding arguments to directives. A lispy
way to do that would be #!(reader <name>).

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.

>     The suggestion that "#! foo" be treated like a string neatly solves the
>     problem of distinguishing directives from comments, but we still have
>     the problem of parsing things inside the directives.
>
> That's true, we need specific parsers. But having no built-in parser is
> much better than advertising the use of a parser made for a different
> language. Something like "a=b c=d" is semantically *not* the list "(a=b
> c=d)". If we want to express this as a Scheme datum, it would be
> something like "((a . b) (c . d))".

You're right. Treating it as Scheme datums is pretending that it's
Scheme; in a sense, we'd be cleaning up after the people who invented
those declarations, by limiting our use of their stuff to a subset to
which we can add some rigor.

>     I do tentatively agree that Scheme should support #!(...) as well.
>
> Strictly speaking, something like "#!r6rs" is not "#! r6rs".

Agreed; they are not intrinsically equal, and we need to make a
deliberate decision about whether or not to interpret them as equal.

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.

So empirically it seems that "#! " would be the best prefix, whether or
not we parse the rest of the line. Typographically "#!" consists of two
prominent characters, so it's also nice that it calls attention to the
fact that there's some unusual data here.

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.

The survey in the 220 rationale shows that the Unix "#!" convention has
led to make Lisp dialects already doing special reading for "#!". So
there would be a good precedent for standardizing "#! " Lisp-wide, and
several existing Lisp readers already ignore text after "#!" until end
of line.

> The former
> sequence is just one token. On the other hand "#! <datum>" would be at
> least two tokens. In fact, the characters "r6rs" following "#!" in
> "#!r6rs" do not even have to form a valid identifier. They just happen
> to look like one.

R6RS does talk about identifiers specifically. Near the start of section
4: " it need not treat the syntax #!identifier, for any identifier (see
section 4.2.4) that is not r6rs, as a syntax violation, and it may use
specific #!-prefixed identifiers as flags indicating that subsequent
input contains extensions to the standard lexical or datum syntax."

AFAIK other editions of RnRS don't talk about identifiers in the context
of "#!", but it's good to keep R6RS precedent in mind.

> So, what we want is a new token, namely "#!", which is then followed by
> a datum, separated by intertoken space. This is, a priori, orthogonal to
> "#!r6rs" and "#!fold-case".

Would we then be able to use "#; #!" for a commented-out directive?