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)
|
> Two things are conflated here, I think. We have the external > representation of Scheme syntax on the one hand, and we have "magic > syntax" like the one you mention that *just happens* to be interpretable > as Scheme datums. However, such syntax should really be interpreted only > as a string. The use of magic comments in other languages a conceptual confusion (an issue they were inevitably bound to hit sooner or later, given their overspecialized syntax). A comment is supposed to be the one part of the syntax that is dedicated to having no machine-parsed meaning, and no machine-parsed structure. Magic comments turn comments' purpose on its head by imbuing them with machine-parsed structure and meaning. But since this is an ad hoc job going against the rules of the language instead of a planned job cooperating with the rules, the structure and meaning are hard to discern and quite brittle. There's a philosophical choice to be made about whether to: (1) Faithfully replicate that conceptual mistake in Scheme, but seal it off into its own corner of the Scheme syntax by adding a dedicated magic comment syntax that is a free-form string after a special prefix. (2) Try to rectify the mistake by recovering as much structure as we can from the magic directives that others have invented. It's true that we can't represent every possible magic comment as Scheme datums, but in practice, it turns out we can represent most of the useful ones. The current 220 draft takes approach (2); you suggest approach (1). > Consider, for example: > > #! MY-Licence-Identifier: ,,GPL-4.0-like´´ > > This is not a sequence of valid external datum representations. > > As we have to distinguish between "#!" and "#! " anyway (see below), the > obvious solution is as follows: > > SRFI 220 does not touch the "#!" syntax but introduces the "#! " syntax. > This is read like ";" but other tools may interpret what follows *as a > string*. [Discussed in the other sub-thread] > I understand this compromise but your use of newlines still seems alien > to the usual Scheme syntax. When outputting several datums in a row, a > pretty printer may still decide to insert newlines (which have counted > just as whitespace), breaking your proposed syntax. That's a good point. The problem is that other languages use magic comments in an intrinsically line-oriented manner. I started out by trying things like (SPDX-License-Identifier: Foo) but That kind of thing either doesn't work that well with other people's parsers, or doesn't look natural in Scheme (e.g. you need to put extra spaces around parentheses, which we otherwise never do). > We should think about whether "#!foo" and "#! foo" should be required > mean the same thing. That probably makes sense; it seems confusing if > they mean something different. > > This won't work with your current proposal. The "#! " syntax has to be > disjoint from the "#!" syntax. For example > > #!r6rs 42 > > is a Scheme datum > > while > > #! r6rs 42 > > under your proposal wouldn't be. > > In other words, the proposed syntax of SRFI 220 has to be orthogonal to > the established "#!" syntax in R6RS and R7RS. [Also in the other sub-thread]