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

Re: SRFI 220: Line directives Vladimir Nikishkin 10 Feb 2021 15:42 UTC

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

No, wait. All of the examples that you are giving in the SRFI, that is
vim-annotations, emacs-annotations, copyrights, licenses, all of them
do not have an effect on the Scheme system itself.
They are used by external tools.

That is point 1.

Point 2:

You are saying that the point of this SRFI is to "If we can turn each
directive into a list of symbols, it becomes easy to programmatically
find all the directives in a Scheme source file."

I am saying that this goal is unrelated to "directives" per se. This
goal is related to "taking a Scheme source file and parsing it as if
it is a meta language".
This "meta language" would have: (1) Executable sexp expressions, (b)
comments, (c) directives. Or maybe I am wrong here, and instead of (1)
it should have (1.1) plain old scheme sexps, (1.2) define-library
language, (1.3) cond-expand language.
Or, maybe some other document structure is there too, that I am not
aware of. (scrible?)

>>IMHO changing syntax in the middle of a file is a really bad idea in general

I love this idea actually. Most of the code I am writing at the moment
is wrapped into Emacs' org-mode.
So, in one file I can easily have 10 languages, and several
interpreters for a language.
And I'm not the only guy in town doing that. E.g. Jupyter notebooks
are loved exactly for that.
Moreover, you can have a poor man's version of that in Bash, but using
a lot of <<<END
here document
END

Point 3.
Maybe I am misunderstanding the whole point of this SRFI?
If you just want to add fancier directives to Scheme, why don't you
write #!(directive argument) ?
This would still be compatible with Scheme's extant !#r7rs, since r7rs
looks like a symbol, and a symbol is a sexp.
So your general syntax would be #!sexp , and it wouldn't be line-oriented.

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

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