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 10 Feb 2021 10:37 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]