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