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 Vladimir Nikishkin 10 Feb 2021 12:56 UTC

On Wed, 10 Feb 2021 at 20:53, Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Mi., 10. Feb. 2021 um 13:47 Uhr schrieb Vladimir Nikishkin <xxxxxx@gmail.com>:
>>
>> 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.
>
> +1
>
> These are exactly my points.
>
>>
>>
>> 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 would lose any local relation between the comments and the scheme datums. I think the API has to be a bit more complicated. It should also cope with comments inside complex datum objects and relate them somehow.
>
> Such an extended reader could, at the same time, return line and column numbers for the Scheme datums read.
>
> Marc
>
>> >
>> > Am Mi., 10. Feb. 2021 um 12:13 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>> >>
>> >> Another angle is that directives meant for external tools with truly
>> >> pathological syntax can still be encoded as a Scheme comment. If #! is
>> >> followed by datums, we can uniformly parse the relatively sane magic
>> >> comments which are essentially sequences of symbols, strings, and
>> >> numbers, maybe with lists for nesting. And we can re-use Scheme's `read`
>> >> for the parsing so it's simple to implement and tractable to understand.
>> >
>> >
>> > No, you can't use Scheme's `read` because it would sometimes interpret the text incorrectly (as shown by my emacs local variable example) or it would produce an error for unparsable datum comments, which can nevertheless be valid in their native DSL syntax.
>> >
>> > The fundamental design flaw also shows up when you consider shebangs: You cannot parse them as you want to parse the rest of the "#! " syntax:
>> >
>> > #! /usr/bin/scheme -I 'a/b/c' -x (
>> > ...
>> >
>> > What happens to the quotes? The open parentheses would be unbalanced, etc.
>> >
>>
>>
>> --
>> Yours sincerely, Vladimir Nikishkin
>> (Sent from GMail web interface.)

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)