Email list hosting service & mailing list manager

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 12:57 UTC

Thanks for commenting (no pun intended).

> I think that there is something wrong going here.
> At some point, "magic comments" sound like an excellent thing. With
> magic comments, I can extend my code with an almost infinite amount of
> metadata.
> On the other hand, Scheme's selling point is exactly the ability to be
> extended beyond the bounds of reason.
> So everything that you would like to put into a "magic comment",
> someone would implement as proper syntax.
>
> So, the point here becomes "trying to cope with the metasyntax
> invented by the other people, who are not even aware of Scheme's
> existence".
> But by proposing a dedicated syntax for "directives" you are
> implicitly trying to regulate what those people "should" do. So this
> proposal seems to be adding more complexity than subtracting.

I see it more as "adopting only a subset of the things other people have
invented", namely the subset that fits into Scheme without deviating
from the exiting syntax in Scheme source files (apart from adding the #!
prefix).

In practice, most magic comments look similar to MIME, email, or HTTP
header syntax -- "Keyword: value". That's fine, but if you look into the
full spectrum of what kinds of data are put into HTTP headers for
example, it's a zoo because they did not start the HTTP spec with a
general syntax like S-expressions that can do nesting in a uniform way.
So different people each invented their own way to do nesting, using
different delimiters.

> I would suggest a simpler thing: procedural comments.
> Just keep the comments as they are (all valid code remains valid), but
> propose a mechanism to process the comments instead of ignoring them.
>
> This would be something like, for example, a recond value returned from (read).
> The first value would be the sexp of the source, the second one would
> be, say a list of strings, where each string, would be a pair
> (line-of-file comment-text), or something like that.
> Perhaps, "load" could do the same, iff it returns.

This is a reasonable suggestion, but the Scheme reader would now return
three kinds of things:

1. Ordinary forms to evaluate as Scheme.

2. Directives (e.g. #!r6rs or #!fold-case).

3. Procedural comments.

Directives and procedural comments have a similar character: both are
metadata to the ordinary Scheme code. Hence it would make sense to unify
them into one concept if that can be done cleanly.

This is something of a personal preference, but I don't see a good way
to embed one syntax in another in general. E.g. think about JavaScript
embedded in HTML embedded in PHP. Or embedded XML documents in some of
the web languages (angle brackets in the middle of curly braces). It
just never looks good, and it's never obvious how to parse it.