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 13:49 UTC

> Again, fine, but I think that having an API for (somehow) working with
> comments is a pre-requisite for an srfi on directives.
> With comments that are like #!fold-case, I don't even know how to do that.
> For example, if some Scheme implements one of those non-sexpy syntax
> srfis, and especially if a file switches the syntax in the middle of a
> file.
> ```
> #!/usr/bin/env my-scheme
> #!r7rs
> (display "hello world1\n")
> #;(comment number one)
> #!my-funky-syntax
> display:
>    "hello world 1\n"
>    /* comment number 2*/
> ```
>
> How would you read that?

The reader has to understand all the directives that change syntax.
#!r6rs the most famous example of such a directive. A reader that
doesn't know what to do about #!my-funky-syntax could not read that file
properly.

IMHO changing syntax in the middle of a file is a really bad idea in
general (PHP and HTML being good examples), and pursuing it leads to
more bad ideas on top, but not everyone agrees, and in theory Scheme
allows something like #!my-funky-syntax to change everything.

>>> I don't see a value in that.
> I see value in that, but I agree that adding "directives" as a
> disjoint entity means needlessly increasing complexity.
>
> I see an IDE reading a file with "read" and getting "something reasonable".

Directives are fundamentally intended to have an effect, and comments
are fundamentally intended to have no effect. That's quite
irreconcilable if we want to have a rational foundation for the
different parts of the syntax.

I agree that directive syntax and comment syntax can look similar, and
that uniformity in surface syntax can be exploited to simplify reading /
processing.

>>> The point of comments is to be ignored by the computer.
> Well, nothing on a computer is truly ignored.

A comment shouldn't affect the semantics of reading or running the
program. (It affects the reader's idea of line and column numbers, but
that's about it.)

> To me, it makes sense to help an IDE as much as possible, even though
> there is not that much that can be done.
> Still, you can keep things valid in the present Schemes, while helping
> and IDE (who is the primary user of those structured comments), a bit,
> without changing the existing syntax.

I agree that parsers and IDEs that can keep comments around and do
things to them are very useful in some cases.
https://github.com/weinholt/laesare is one Scheme reader that reads
comments.

However, comments and directives fundamentally serve a different purpose
(save for the magic comments hack that some languages have embraced; but
then again, JavaScript has done magic strings by having the literal "use
strict;" have special meaning; there's no end to what can be done with
duct tape and bubble gum :)

Many Lisp systems have a code walker that can help do transformations to
the source code beyond what ordinary macros can. It would probably make
sense to have one for Scheme as well.