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)
|
> - If #! is followed immediately by a horizontal whitespace character, > read datums until end-of-line. If exactly one datum was read, and it's > either an empty list or a pair, return it. Otherwise wrap any and all > datums in an implicit list and return that list. > > That's bad IMO because of the implicit wrapping in pairs, which only > happens in some of the cases. This can destroy read-write invariance. If > you want to make it possible for more than one datum to follow, enclose > everything uniformly in a list. That's true. It's hard to find a compromise that works well from both Lisp tradition's and line-oriented parsers' perspective, as S-expressions are fundamentally not line-oriented. > The SRFI would, however, still be built on the wrong assumption, namely > that everything that usually follows "#! " in a Scheme file is parsable > as a sequence of datums. The elements in a shebang don't have to be > parsable as such. Let "#! " return what it reads as a string. The string > has to be parsed, of course, but this shouldn't be done by the Scheme > reader because the string does not necessarily consist of Scheme syntax. That does make some sense. In that case we could have different parsing rules for the line of text that follows. However, it doesn't solve the fundamental problem that magic comments encode data using an internal, ad-hoc syntax similar to programming language syntax. So it's like embedding XML inside S-expressions: XML does the same job, but in a gratuitously different way, leading to a confusing and IMHO aesthetically displeasing result :) Ideally string literals would be restricted to natural language text which doesn't have the kind of formal structure that code does, and we could represent everything else as S-expressions (as we now do turning XML into SXML for example).