SRFI 4 lexical syntax John Cowan (06 Dec 2023 04:03 UTC)
Re: SRFI 4 lexical syntax Arthur A. Gleckler (06 Dec 2023 04:07 UTC)
Re: SRFI 4 lexical syntax John Cowan (06 Dec 2023 13:13 UTC)
Re: SRFI 4 lexical syntax Marc Feeley (07 Dec 2023 04:20 UTC)
Re: SRFI 4 lexical syntax John Cowan (07 Dec 2023 08:20 UTC)
Re: SRFI 4 lexical syntax Marc Nieper-Wißkirchen (07 Dec 2023 09:07 UTC)
Re: SRFI 4 lexical syntax Marc Feeley (07 Dec 2023 14:25 UTC)
Re: SRFI 4 lexical syntax Marc Nieper-Wißkirchen (07 Dec 2023 15:17 UTC)
Re: SRFI 4 lexical syntax Marc Feeley (07 Dec 2023 16:01 UTC)
Re: SRFI 4 lexical syntax Arthur A. Gleckler (07 Dec 2023 16:27 UTC)
Re: SRFI 4 lexical syntax Per Bothner (07 Dec 2023 17:20 UTC)

Re: SRFI 4 lexical syntax Marc Feeley 07 Dec 2023 16:01 UTC

> On Dec 7, 2023, at 10:17 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> Speaking of warts, we already have to bring #u8 and #vu8 together. :)

This would needlessly introduce a wart in the language with two syntaxes for the same thing.

The “v” in the #vu8, etc syntax was an misguided choice to allow using a single character lookahead after the “#” to determine that what follows is a bytevector. But this doesn’t help much because the “u8” after the “v” has to be read anyway to know what kind of bytevector. From my time as editor of the R6RS I recall the real reason was that “#f64(…” meant that a single character lookahead after “#” was not sufficient to distinguish “#f” from “#f64(…”. But this is such a simple thing to solve in the parser that I find the argument very weak.

It is less work for the R6RS implementations that wish to be compatible with R7RS-large to extend their parser (probably 10 lines of code at most?) than to require all implementations of Scheme (R6RS compatible or not) to implement both syntaxes, and end up with a wart in R7RS-large.

By the way, this is another example of the consequences of not adopting established practice when designing a standard (SRFI-4 dates back to 1998 and R6RS came about 9 years later).

Marc