Email list hosting service & mailing list manager

Scheme Review bootstrapped Lassi Kortela (01 Dec 2022 22:25 UTC)
Re: Scheme Review bootstrapped John Cowan (02 Dec 2022 12:10 UTC)
Re: Scheme Review bootstrapped Marc Feeley (02 Dec 2022 12:16 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 13:24 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 13:37 UTC)
Re: Scheme Review bootstrapped Marc Nieper-Wißkirchen (02 Dec 2022 14:58 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 15:10 UTC)
Re: Scheme Review bootstrapped Marc Nieper-Wißkirchen (02 Dec 2022 16:24 UTC)
Scheme Review vs. SRFIs John Cowan (03 Dec 2022 22:07 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (03 Dec 2022 22:39 UTC)
Re: Scheme Review vs. SRFIs Arthur A. Gleckler (03 Dec 2022 23:25 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (04 Dec 2022 00:14 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 00:50 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (04 Dec 2022 09:34 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 10:01 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (04 Dec 2022 11:07 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 11:44 UTC)
Re: Scheme Review vs. SRFIs Arthur A. Gleckler (04 Dec 2022 05:15 UTC)
Re: Scheme Review vs. SRFIs Vladimir Nikishkin (04 Dec 2022 06:27 UTC)
Re: Scheme Review vs. SRFIs Arthur A. Gleckler (04 Dec 2022 06:31 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 13:28 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 07:13 UTC)
Re: Scheme Review vs. SRFIs Vladimir Nikishkin (04 Dec 2022 07:28 UTC)
Re: Scheme Review vs. SRFIs Marc Nieper-Wißkirchen (04 Dec 2022 09:40 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 13:16 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 09:41 UTC)
Re: Scheme Review vs. SRFIs Vladimir Nikishkin (04 Dec 2022 10:06 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 10:15 UTC)
Re: Scheme Review vs. SRFIs Vladimir Nikishkin (04 Dec 2022 10:44 UTC)
Re: Scheme Review vs. SRFIs Marc Nieper-Wißkirchen (04 Dec 2022 09:57 UTC)
Re: Scheme Review vs. SRFIs elf (04 Dec 2022 10:59 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 20:20 UTC)
Re: Scheme Review vs. SRFIs Wolfgang Corcoran-Mathe (04 Dec 2022 18:01 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (04 Dec 2022 22:09 UTC)
Re: Scheme Review vs. SRFIs elf (05 Dec 2022 13:31 UTC)
Re: Scheme Review vs. SRFIs Marc Nieper-Wißkirchen (05 Dec 2022 13:53 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 13:59 UTC)
Re: Scheme Review vs. SRFIs Arvydas Silanskas (05 Dec 2022 16:43 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 17:44 UTC)
Re: Scheme Review vs. SRFIs Arthur A. Gleckler (06 Dec 2022 00:15 UTC)
Re: Scheme Review vs. SRFIs Wolfgang Corcoran-Mathe (05 Dec 2022 18:08 UTC)
Re: Scheme Review vs. SRFIs Lassi Kortela (05 Dec 2022 18:25 UTC)
Re: Scheme Review vs. SRFIs John Cowan (05 Dec 2022 03:47 UTC)
Re: Scheme Review bootstrapped Jakub T. Jankiewicz (02 Dec 2022 18:18 UTC)
Re: Scheme Review bootstrapped Arthur A. Gleckler (02 Dec 2022 18:34 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 18:39 UTC)
Re: Scheme Review bootstrapped Jakub T. Jankiewicz (02 Dec 2022 18:50 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 21:33 UTC)
Re: Scheme Review bootstrapped Jakub T. Jankiewicz (02 Dec 2022 22:16 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (02 Dec 2022 22:34 UTC)
Re: Scheme Review bootstrapped Jakub T. Jankiewicz (03 Dec 2022 11:24 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (03 Dec 2022 13:47 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (03 Dec 2022 14:05 UTC)
Re: Scheme Review bootstrapped Jakub T. Jankiewicz (03 Dec 2022 15:04 UTC)
Re: Scheme Review bootstrapped Lassi Kortela (03 Dec 2022 15:22 UTC)

Re: Scheme Review vs. SRFIs Lassi Kortela 05 Dec 2022 17:44 UTC

I for one don't have a problem with your tone.

> Realistically there is little benefit of having more than ~5 (one for
> fast standalone, one for scripting, a couple for targeting various
> environments like JVM or CLR etc)

Different 5 for everybody. Yes, some implementations have almost the
same niche. But there are surprisingly many niches.

> The fracturing of users / libraries,
> the duplication of work across different implementations is immensely
> saddening to me. I don't know what the ideal solution should be.

Merging existing implementations is something even I wouldn't attempt to
persuade their authors to do. Though in some cases users would benefit.

If I were forced to attempt this, I would start by trying to persuade
authors to share individual subsystems (e.g. GC, FFI, some libraries).

I don't think we have any SRFIs specifying how the internals of a Scheme
implementation should look, but the concept would make sense.
Standardized internal interfaces would make it easier to navigate the
codebase of an unfamiliar implementation, and would build bridges toward
eventually sharing the implementations of some of those interfaces. I
wouldn't expect any implementer to have time for this, but some loyal
users might.

I won't do any of the above; just throwing the sketch out there.

> My
> tentative hope is that a cohesive set of SRFIs grouped under a label of
> R7RS-large would eventually establish a strong core of scheme
> implementations and more or less cull the rest. With this mindset I
> don't think it is necessary for the SRFI process to be
> "Scheme-community-wide", because the scheme community would adapt to the
> designed pieces after the fact.

Despite the brashness of my approach to Scheme, I always try to serve
everybody - try to create a world where every current player has a
place, even if that player doesn't share my design sensibilities. People
with the attitude you describe are trying to serve themselves - create a
world where those with inconvenient opinions are cast aside. The problem
with that is, everyone has a different view of who's inconvenient.
You're unlikely to achieve unity that way.

At any given time, "the rest" of the implementations "cull" themselves.
Some implementers are bound to be more driven and/or lucky than others,
making those implementations have the most users or development effort.

Which implementations constitute "the rest"? Now, that changes over
time. Open source projects can always be resurrected.

A strong core is unlikely to come from a process that so far doesn't
include Bigloo, Chez, Chicken, Gambit, Guile, Kawa, Loko, MIT Scheme.
Perhaps it will include them in the future, but you've got your work cut
out for you.