Email list hosting service & mailing list manager

Second round of proposals for directives Lassi Kortela (17 Feb 2021 08:34 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (17 Feb 2021 08:53 UTC)
Re: Second round of proposals for directives Lassi Kortela (17 Feb 2021 09:25 UTC)
Re: Second round of proposals for directives Lassi Kortela (17 Feb 2021 09:43 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (17 Feb 2021 09:51 UTC)
Re: Second round of proposals for directives Lassi Kortela (17 Feb 2021 10:11 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (17 Feb 2021 10:31 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (17 Feb 2021 09:44 UTC)
Re: Second round of proposals for directives Lassi Kortela (17 Feb 2021 10:01 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (17 Feb 2021 10:43 UTC)
Re: Second round of proposals for directives John Cowan (18 Feb 2021 02:56 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (18 Feb 2021 10:37 UTC)
Re: Second round of proposals for directives Vladimir Nikishkin (18 Feb 2021 15:42 UTC)
Re: Second round of proposals for directives Marc Nieper-Wißkirchen (18 Feb 2021 15:51 UTC)

Re: Second round of proposals for directives Vladimir Nikishkin 18 Feb 2021 15:41 UTC

>It's also not the case that magic comments are only for external tools.
>Kawa and Gauche already parse encoding comments. This is a good example

But these are two different things, aren't they?
File encoding from the point of view of the Scheme system, and the
file from the editor's viewpoint, are not the same!

It believe, it is perfectly valid to have in one file:
#!/usr/bin/env scheme
; -*- coding: ascii-oem; -*-
#,(set-input-port-encoding!
  utf8)

Why would you want that? For example, if you want to see your file
literally byte-by-byte in the editor, to make sure that all the byte
sequences are correct.
But you would still want your Scheme to read it as an utf-8 encoded file.

(Here two things are hypothetical. The ascii-oem character encoding is
a hypothetical charset that is the same as ascii below 127, and
everything above is represented with "tofu" characters, which help to
debug byte sequences. The ,(declare) thing is an imaginary Scheme
reader function that makes the reader expect utf8.

On Thu, 18 Feb 2021 at 18:37, Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Do., 18. Feb. 2021 um 03:56 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>>
>>
>>
>> On Wed, Feb 17, 2021 at 5:43 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>>
>>> All these are incompatible with R6RS, where "#!"-prefixed identifiers must be read "as flags indicating that subsequent input contains extensions to the standard lexical or datum syntax".
>>
>>
>> Such a flag may have a dual import: this is not R6RS lexical syntax, and it has a particular meaning.  For example, #!eof can serve as an indicator of a lexical syntax that says that #!eof is an identifier immutably and unshadowably bound to an object that satisfies `eof-object?`.  R6RS implementations that don't support this will of course puke on it.
>
>
> Possibly, this is covered. But even if, I don't think that it is a good idea to unite a flag (which is not a datum) with a datum.
>
>>
>> In any case, I don't care about R6RS MUSTard.  Otherwise I have no dog in this fight, except that a line beginning "#!/" should be treated as a single-line comment in order to make standard Posix-style scripting work (this is not part of the Posix standard, but is almost universally implemented).
>
>
> I know that William Clinger likes the word mustard in connection with R6RS but this doesn't necessarily turn it into a good habit. For writing portable and safe programs, the "mustard" in R6RS helps a lot. I don't want to say that it is absolutely best (when it comes to experimentation, R7RS's lenience has a lot of advantages), but it has a lot of virtues on its own.
>
> What many people haven't understood is that what you call "mustard" is much less confining than usually claimed. With respect to library procedures, an implementation is only forced to obey it when the procedures are exported through (rnrs (6)). It is exactly the library system (and the fact that there are no predefined identifiers) that the "mustard"
> does not at all need to limit interoperability.
>
> Now, the corner case where the library system is not sufficient to get maximal portability and interoperability is the reader because it does not start "blank". That's why the idea of an "#!r6rs" flag is important.
>
> R6RS is a Scheme like R7RS. It is different than R7RS but not inferior. I don't think it helps the Scheme community to ignore the virtues of R6RS.
>
> PS As for "#!/" being treated as the beginning of a line comment, as explained in the other thread I believe that this would cement a wrong understanding of the role of the magic line in a Scheme script source.
>

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