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)
|
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.