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