Making SRFI go faster Lassi Kortela 25 Apr 2021 09:33 UTC
Re: Making SRFI go faster Vladimir Nikishkin 25 Apr 2021 09:46 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 09:57 UTC
Re: Making SRFI go faster Amirouche Boubekki 25 Apr 2021 11:04 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 11:13 UTC
Re: Making SRFI go faster Marc Feeley 25 Apr 2021 12:01 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 12:15 UTC
Re: Making SRFI go faster Alex Shinn 26 Apr 2021 13:09 UTC
Re: Making SRFI go faster Jakub T. Jankiewicz 26 Apr 2021 18:51 UTC
Re: Making SRFI go faster Alex Shinn 27 Apr 2021 02:59 UTC
Re: Making SRFI go faster Amirouche Boubekki 25 Apr 2021 10:47 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 10:57 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 11:03 UTC
Re: Making SRFI go faster Adam Nelson 25 Apr 2021 21:00 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 21:10 UTC
Re: Making SRFI go faster Amirouche Boubekki 25 Apr 2021 11:34 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 12:01 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 25 Apr 2021 12:23 UTC
R6RS and portability Lassi Kortela 25 Apr 2021 12:35 UTC
Re: R6RS and portability Marc Nieper-Wißkirchen 25 Apr 2021 14:18 UTC
Re: R6RS and portability Marc Feeley 25 Apr 2021 14:41 UTC
Re: R6RS and portability Marc Nieper-Wißkirchen 25 Apr 2021 14:55 UTC
Scheme package management Lassi Kortela 25 Apr 2021 15:03 UTC
Re: Scheme package management Marc Feeley 25 Apr 2021 15:08 UTC
Re: Scheme package management Lassi Kortela 25 Apr 2021 15:14 UTC
Re: Scheme package management Alex Shinn 26 Apr 2021 08:14 UTC
Re: Scheme package management Lassi Kortela 26 Apr 2021 09:02 UTC
Re: Scheme package management Alex Shinn 26 Apr 2021 09:33 UTC
Re: Scheme package management Lassi Kortela 26 Apr 2021 09:41 UTC
Re: Scheme package management Jakub T. Jankiewicz 26 Apr 2021 12:01 UTC
Re: Scheme package management Lassi Kortela 26 Apr 2021 12:09 UTC
Re: Scheme package management Alex Shinn 26 Apr 2021 12:58 UTC
Re: Scheme package management Alex Shinn 26 Apr 2021 12:34 UTC
Re: R6RS and portability Marc Feeley 25 Apr 2021 15:05 UTC
Re: R6RS and portability Marc Nieper-Wißkirchen 25 Apr 2021 15:14 UTC
Scheme package management Lassi Kortela 25 Apr 2021 15:22 UTC
Re: Scheme package management Marc Nieper-Wißkirchen 25 Apr 2021 15:35 UTC
Re: Scheme package management Lassi Kortela 25 Apr 2021 15:45 UTC
Re: Scheme package management Marc Nieper-Wißkirchen 25 Apr 2021 15:51 UTC
Re: Scheme package management Lassi Kortela 25 Apr 2021 16:27 UTC
Re: Scheme package management Marc Feeley 25 Apr 2021 15:47 UTC
Re: Scheme package management Lassi Kortela 25 Apr 2021 15:54 UTC
Scheme package management Marc Feeley 25 Apr 2021 15:28 UTC
Re: Scheme package management Marc Nieper-Wißkirchen 25 Apr 2021 15:41 UTC
Re: R6RS and portability Jakub T. Jankiewicz 25 Apr 2021 15:55 UTC
Re: R6RS and portability Lassi Kortela 25 Apr 2021 16:15 UTC
Re: Making SRFI go faster Adam Nelson 25 Apr 2021 20:56 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 25 Apr 2021 21:14 UTC
Re: Making SRFI go faster Adam Nelson 25 Apr 2021 21:29 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 21:40 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 26 Apr 2021 06:05 UTC
Re: Making SRFI go faster Marc Feeley 25 Apr 2021 21:07 UTC
Re: Making SRFI go faster Adam Nelson 25 Apr 2021 21:34 UTC
Building up R7RS in stages Lassi Kortela 25 Apr 2021 21:45 UTC
Re: Making SRFI go faster Marc Feeley 25 Apr 2021 21:59 UTC
Re: Making SRFI go faster Amirouche Boubekki 26 Apr 2021 06:54 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 25 Apr 2021 11:36 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 11:47 UTC
Re: Making SRFI go faster Adam Nelson 25 Apr 2021 20:11 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 25 Apr 2021 20:30 UTC
Re: Making SRFI go faster John Cowan 25 Apr 2021 23:04 UTC
Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 20:29 UTC
Re: Making SRFI go faster Wolfgang Corcoran-Mathe 26 Apr 2021 02:45 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 26 Apr 2021 05:58 UTC
Re: Making SRFI go faster Lassi Kortela 26 Apr 2021 06:45 UTC
Re: Making SRFI go faster Amirouche Boubekki 26 Apr 2021 07:05 UTC
Interaction between spec and code Lassi Kortela 26 Apr 2021 07:36 UTC
Re: Interaction between spec and code Marc Nieper-Wißkirchen 26 Apr 2021 07:59 UTC
Re: Interaction between spec and code Lassi Kortela 26 Apr 2021 08:06 UTC
Re: Interaction between spec and code Marc Nieper-Wißkirchen 26 Apr 2021 08:16 UTC
Re: Interaction between spec and code John Cowan 30 Apr 2021 14:39 UTC
Re: Interaction between spec and code Lassi Kortela 30 Apr 2021 14:56 UTC
Re: Interaction between spec and code John Cowan 01 May 2021 05:02 UTC
Re: Making SRFI go faster John Cowan 26 Apr 2021 00:28 UTC
Spec vs code, user-driven vs designer-driven Lassi Kortela 26 Apr 2021 06:15 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 01 May 2021 06:34 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 07:02 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 08:14 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 09:11 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 09:56 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 10:29 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 11:01 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 11:32 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 12:09 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 12:49 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 13:34 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 14:01 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 14:39 UTC
Re: Spec vs code, user-driven vs designer-driven Per Bothner 01 May 2021 15:37 UTC
Re: Spec vs code, user-driven vs designer-driven Amirouche Boubekki 01 May 2021 14:10 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 15:04 UTC
Re: Spec vs code, user-driven vs designer-driven Amirouche Boubekki 01 May 2021 16:43 UTC
Re: Spec vs code, user-driven vs designer-driven Adam Nelson 01 May 2021 17:35 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 01 May 2021 17:55 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 01 May 2021 18:31 UTC
Discussion with the creator of Lojban, and editor of R7RS-large Amirouche 01 May 2021 23:35 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large John Cowan 02 May 2021 01:29 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large Arthur A. Gleckler 02 May 2021 02:08 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large John Cowan 02 May 2021 03:51 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large Arthur A. Gleckler 02 May 2021 04:16 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large John Cowan 02 May 2021 05:55 UTC
Re: Discussion with the creator of Lojban, and editor of R7RS-large Amirouche 02 May 2021 11:26 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 02 May 2021 17:21 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 01 May 2021 18:12 UTC
Re: Spec vs code, user-driven vs designer-driven Arthur A. Gleckler 01 May 2021 18:21 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Feeley 01 May 2021 18:37 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 01 May 2021 20:18 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 01 May 2021 17:08 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 16:30 UTC
Re: Spec vs code, user-driven vs designer-driven Faré 03 May 2021 02:24 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 03 May 2021 09:49 UTC
Re: Spec vs code, user-driven vs designer-driven Faré 03 May 2021 14:19 UTC
Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 03 May 2021 14:33 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 03 May 2021 14:41 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 03 May 2021 15:00 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 03 May 2021 19:46 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 03 May 2021 20:43 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 03 May 2021 23:49 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 04 May 2021 07:33 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 05 May 2021 18:33 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 05 May 2021 18:51 UTC
Re: Spec vs code, user-driven vs designer-driven John Cowan 05 May 2021 20:12 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 05 May 2021 20:26 UTC
Re: Spec vs code, user-driven vs designer-driven Amirouche 05 May 2021 21:37 UTC
Re: Spec vs code, user-driven vs designer-driven Alex Shinn 05 May 2021 21:50 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 06 May 2021 13:18 UTC
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen 03 May 2021 14:27 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 26 Apr 2021 08:09 UTC
Re: Making SRFI go faster Lassi Kortela 26 Apr 2021 08:15 UTC
Re: Making SRFI go faster Marc Nieper-Wißkirchen 26 Apr 2021 08:26 UTC

Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 12:09 UTC

>     The unfortunate thing about standards is that what wins is whatever
>     succeeds at establishing agreement.
>
> This isn't a good yardstick. Or R5RS would be the best of all.

On the contrary, R5RS is an excellent illustration of the principle --
it still is the most successful Scheme standard of all, even more so
than R7RS-small. Even non-schemers revere R5RS.

I suspect that R7RS-small is near the upper limit of how complex a
successful Scheme standard can be without relying on optional features.

> Uniting R7RS-small with R6RS isn't too hard because it would be
> basically R6RS+epsilon. The harder part would be to convince the
> R7RS-small people that adding the R6RS stuff is good.

Exactly!

If the R6RS parts are optional, then implementations like Chibi and
TinyScheme could still aim at conformance while keeping out the most
complex stuff.

Even simple compatibility such as supporting the same read syntax for
symbols and vectors, and supporting both (library ...) and
(define-library ...), would be a big help in practice. Every extra bit
of compatibility helps. Having a unified R6RS+R7RS standard would
encourage even the small implementations that leave out the complex
features, to eventually support the R6RS and R7RS variants of those
features that they do implement. This would add up to a lot more
real-world code being portable. It would obviate the need to mess with
command line flags like `-r 6` and `-r 7`, #!r6rs directives, .sld vs
.sls extensions, etc.

And perhaps equally importantly, uniting all schemers under the standard
with the same name would have a positive psychological impact and stop
our repeated exegeses about Scheme history that we cannot change :)

>     We come back to the unfortunate fact that successful standards
>     establish
>     agreement. R6RS is a successful language but an unsuccessful standard.
>
> Chez, Racket, and Guile are among the most successful Scheme
> implementations. And they are all based on the R6RS (or have moved
> there). In the case of Racket and Guile (and to a smaller extent also
> Chez), they have moved much further, of course, but implement R6RS
> nonetheless.

You have a point. R6RS has successfully standardized the core features
across important implementations.

>     It's possible to design a good language that is also a good standard
>     (i.e. reflects the consensus of the community). Scheme being in the
>     state that it is, the only way to do that is factoring it heavily into
>     optional features.
>
> That could be an approach for R8RS (= R6RS + R7RS-small) if "optional"
> is not restricted to libraries.

Agreed.

In particular, macro systems would be profitable to standardize in RnRS.
You have done excellent work cataloging them with your SRFIs. There's no
reason RnRS couldn't have something like explicit-renaming as an option,
considering that ER is already widely implemented in practice.

Macro systems are not as tractable to add as libraries outside RnRS.
It's all this compatibility glue that RnRS reports are uniquely well
positioned to deal with. We can write third-party compatibility shims of
all kinds, but the experience is never as nice as having all that good
stuff built in.

>     R6RS is compatible with R5RS, but R6RS set future RnRS reports up to
>     fail. A standard should never do that. The R6RS continuity plan for
>     R7RS+ was "our way or the highway". What if it turns out the wider
>     commmunity doesn't want all those features? Too bad for them.
>
> Why wouldn't be future reports based on R6RS possible?

They are very much possible, but what I mean is that R6RS locked future
reports into a particular direction that wasn't based on a consensus.

My opinion is that compatibility is the most important job of a
standard; it directly follows that future reports can add stuff to the
last report but not remove stuff. (They can make some previously
optional stuff required, or required stuff optional, eventually phasing
out optional stuff that nobody has used in a while. But it's not
acceptable to remove stuff from the previous report. That's what caused
the really big problems with Python 3; some code simply couldn't be
written in a way that works in both 2 and 3, making the transition
period painful for library authors.)

 From this point of view, R6RS added lots of stuff that R7RS has a moral
obligation to support. R7RS didn't accept this obligation (reflecting
the lack of consensus among implementers). The combined actions of R6RS
and R7RS caused us to end up with this debate.

I'd argue that R6RS did the greater wrong because it added controversial
stuff. They should first have written the implementations, and if
consensus emerges, then the standard. Or written a standard by some
other name than RnRS, RnRS being the flag bearer of Scheme.

But since R6RS already did its deed and it was finalized, the moral duty
(perhaps an unsavory one, but duty nonetheless) to maintain
compatibility has now been passed to R7RS.

If R7RS further adds new controversial stuff, it does the same thing
R6RS did, and if finalized, passes the moral duty onto R8RS to keep all
that controversial stuff.

At present, Scheme is in a cycle where RnRS designers are wed to their
personal vision and pass that vision onto the current implementers and
the next RnRS designers. Implementers grumble, designers resent prior
designers, the prior designers resent the next designers, and the
community is ambivalent, apathetic, or disillusioned.

These psychological reactions and attitudes are not unexpected. They are
a predictable consequence of a process where the RnRS stewards are
visionaries rather than scholars. A good scholar is diligent (which John
is, to a truly incredible extent), and tries to translate the source
material faithfully, adding as few of his own interpretations as he can.

> I doubt that all the R7RS-large libraries will have to go into the next
> formal RnRS report. For that, the libraries are too diverse and
> inconsistent. At least a thorough clean-up effort would be needed.

There are easily predictable psychological consequences to the entire
community if each RnRS drops half the stuff from the prior RnRS. The
process shouldn't be a Sisyphean task where each RnRS group rolls a
boulder uphill, the next group rolls it halfway back down, and then up
again.

And adding new people to the community is hard if no-one can figure out
which of the warring RnRS, if any, is legitimate.

> Besides psyntax, there is André van Tonder's implementation (shipped
> with Larceny). Then there is my own implementation in the form of
> Unsyntax. And there is the implementation I wrote for Chibi Scheme. Jim
> Rees has his own implementation, etc.
>
> The source code of the Chez Scheme compiler is very readable. It also
> includes a syntax-case implementation, of course. Maybe you want to take
> a look at that. Kent Dybvig's and his student's papers on syntax-case
> and the library system are very well-written.

Great, the situation is much better than I suspected. Congratulations
for implementing it on your own; not an easy job!