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