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

Comments are not scheme datums. That's the point of comments. If they
could be written in scheme datums, they would have been Scheme datums.
But they are not.
Or, rather, they may be Scheme strings, as far as I understand.

I am not saying that the single line sketch of the API I mentioned is
by any way extensive.
But I think that if such an API is proposed/implemented, it would
subsume the proposed SRFI.
If you have a programmatic way to distinguish between "code" and
"comments", you have much more freedom when dealing with the comments.

I am thinking that there are some things that are guaranteed to exist:
line numbers, comment-type (i.e. semicolon-comment, shebang, srfi-62
comments, multiline comments, possibly others), comment content,
character encoding (?), comment body, maybe something else?
A proper list would require some more thinking, but having such an API
would give way more freedom in trying to find metacode, such as
license and coding in the file.

>>now return three kinds of things:

Aren't directives actually comments?

Or, rather, if the reader being extended to properly read shebangs,
doesn't it make sense to properly read comments (instead of ignoring)
at the same time?

On Wed, 10 Feb 2021 at 20:57, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> 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.

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