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)
|
> While it is still unclear what you exactly mean by "#! directive", It's not that important what we mean by the word because the concept isn't that well developed. RnRS only has a small handful of directives. I'm using it to mean something that doesn't cause a datum to come out of `(read)`. But a lot of the existing #! does emit a datum, which shows that "doesn't emit a datum" may not be a good principle for "#!" to have in RnRS. > taking the above list as examples, it is clear the shebang lines are no > directives in this sense and can and should be left out of the discussion. A shebang line shouldn't emit a datum out of `(read)`, but can benefit from other processing, so I think it fits fine with directives. You could say a directive has to affect reader state. A shebang line can affect reader state (e.g. "#! /usr/bin/env r7rs-script" could switch to R7RS read syntax) but does not have to. #!nocache already exists and doesn't affect reader state either. > #!key > #!optional > #!rest > > What do you mean by "only valid inside a lambda list"? The reader > doesn't know the concept of a lambda list. You're right. In Gambit and Kawa you can type stuff like (eq? #!optional #!optional) and it works. So these are implemented as self-evaluating objects. In Kawa #:foo needs to be quoted explicitly, similar to vector literals in R6RS. Similarly one could require '#!optional and such. But this is not reader-level stuff either.