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 Lassi Kortela 11 Feb 2021 10:05 UTC

>>> Directives are fundamentally intended to have an effect
>
> 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.

You're right, but from a systems point of view, an effect on external
tools is still an effect. For example, "#! SPDX-License-Identifier: MIT"
can affect tools that figure out what license a package has. Emacs and
Vim settings have meaning to Emacs and Vim.

Perhaps the clearest way to think about comments is that turning a
non-comment part of the program into a comment should disable that part.
The S-expression comment #;(foo (bar (baz))) has structure but it has no
effect on Scheme, and if external tools are designed in a principled
way, it should have no effect on them either. The "#;" is telling the
reader to disable whatever effect (foo (bar (baz))) would ordinarily have.

You can't disable a magic comment by turning it into some kind of
commented-out-comment in this way. That's one of the main reasons the
approach is unsound.

If a comment means "this part can and should be ignored by all parsers"
that gives us a useful baseline. But we'd still be left with the classic
problem of which _non-comment_ parts are safe to ignore and which are
not. That hard and I've never seen an ideal solution.

If files state which license they use, and a package manager is given a
command to block files with a given license, then it's not safe to
ignore license information. If a git hook formats code before
committing, it's not safe to ignore formatting settings.

The same problem comes up with optimization settings and the like. In
Common Lisp a function can say (declare (optimize (speed 3))). Is that
safe to ignore? Probably not if the application is performance-critical.
Lots of systems would break around the world if GCC ignored the -O2 or
-O3 optimization flag.

As a practical matter, we should make some kind of distinction between
things that affect Scheme evaluation semantics ("correctness"?) and
things that don't. Currently flags like #!r6rs and #!fold-case affect
it, so we need to preserve some way of distinguishing those flags.

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

That goal is related to the distinction between comments and directives.

If directives have a known lexical structure, and are clearly
distinguished from comments, that makes directives much easier to parse
without using heuristics.

If directives may be tucked into comments, and no claim is made about
what lexical structure they may have internally, the parser has to rely
entirely on heuristics.

The suggestion that "#! foo" be treated like a string neatly solves the
problem of distinguishing directives from comments, but we still have
the problem of parsing things inside the directives.

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

The meta-language is a good idea, but orthogonal to how directives are
written in Scheme's surface syntax. I don't know to what extent Scheme
already has a formal meta-language; at the very least, R7RS needs to
distinguish between libraries and programs.

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

It's true that markup languages that embed code snippets are unavoidably
useful, and it's useful if you can mix code snippets from different
programming languages in the same markup document.

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

I do tentatively agree that Scheme should support #!(...) as well.