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:05 UTC)
Re: Making SRFI go faster Lassi Kortela (25 Apr 2021 11:14 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:04 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:04 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:15 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:35 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:12 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 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:03 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:12 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:33 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:02 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:32 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 Arthur A. Gleckler (02 May 2021 04:16 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:20 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:01 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (03 May 2021 19:47 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:34 UTC)
Re: Spec vs code, user-driven vs designer-driven Marc Nieper-Wißkirchen (05 May 2021 18:52 UTC)
Re: Spec vs code, user-driven vs designer-driven John Cowan (05 May 2021 20:13 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:27 UTC)
Re: Making SRFI go faster Wolfgang Corcoran-Mathe (26 Apr 2021 02:46 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:06 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:17 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: 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!