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
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
Marc Nieper-Wißkirchen
(10 Feb 2021 12:25 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?