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 08:14 UTC

> I think a very good thing about the R7RS-large effort is the large
> number of SRFIs it has been and is producing because it is moving the
> Scheme language forward.
>
> The actual purpose of the R7RS-large effort, namely creating a ratified
> language spec by declaring some of the SRFIs as "offical", is far less
> important IMHO. Actually, I am no longer convinced that it is a good
> goal for a number of reasons:
>
> * Far too few people (especially implementers) are active in the process.
> * Even fewer people review, test and implement proposed SRFIs.
> * The voting process can too easily yield arbitrary results depending on
> who votes.
> * The SRFIs making up R7RS-large handle similar things often very
> differently.
> * We often have just one implementation of a SRFI. Implementers of the
> very fast implementations like Chez don't give feedback whether
> implementing them would compromised performance.
>
> So when R7RS-large is finalized, we are simply giving a number of SRFIs
> "official" status. The nice thing about it is that the can be accessed
> through simple names like "(scheme list)". But, as John writes, this
> also means that the underlying SRFI can only be replaced by an upward
> compatible one.
>
> R6RS has library versioning, which would have helped. We would finalize
> "(scheme list (7))" but that wouldn't exclude a different "(scheme list
> (8))". Of course, there's always the possibility that we get back a
> (stripped-down) form of library versioning back in the R7RS world.
>
> Please read again the first sentence. While this may not have been the
> original goal of the R7RS-large process, it shows that it has already
> been highly successful. We owe you a lot just for this, John.

I basically agree with everything Marc said, both the praise and the
plea for change, for the reasons he states. I also feel apologetic and
self-conscious about directing so much criticism at R7RS-large (even
though it's intended to be constructive and in good faith) since in
practice John has to shoulder so much of the responsibility personally.

R6RS was polarizing because it was a de jure standard that wasn't (and
still isn't) a de facto standard. It didn't achieve de facto status
because it added so much new stuff not backed by a consensus. The voting
record shows that even the working group was divided internally but
they forged ahead anyway.

R7RS-small is a successful consensus standard, and -large mainly adds
libraries on top of it, so -large is better positioned than R6RS in this
respect. There are few changes to the core language on top of the
consensus standard.

However, the same process artifacts are showing as with R6RS: there is
not broad consensus within the Scheme community about which R7RS-large
libraries to adopt, and no working group internal consensus either. (WG2
members who disagree with the general direction tend to become passive
or leave. In R6RS I assume most of them stayed but were outvoted.)

I believe this outcome is not peculiar to R6RS or to R7RS-large, but is
inherent in making any de jure standard that doesn't start from a de
facto consensus. It's not about individual decisions made; it's
inevitable due to the scope of the standard, which has been extended to
cover areas of the language about which there isn't a consensus.

IMO a standard has the moral duty to establish long-term agreement among
implementers. The larger the scope of the standard, and the more novel
stuff there is, the more difficult it is to uphold that duty. Something
like R7RS-small is: people may grumble about the precise syntax or
semantics of define-record-type or define-library, but implementers
agree that the language should have records and libraries in something
like their current form.

There isn't similar agreement about what data structures and libraries
the language should have (beyond lists, vectors, bytevectors, strings,
and hash tables).

Not only is near-term agreement important, but long-term agreement
across the decades. This means that when writing a standard, succession
should be planned in from the start. We should make it easy for writers
of future Scheme reports to keep in agreement with the de facto
consensus among future implementers. Since we lack the requisite
foresight, the best bet is to be conservative and standardize things
that are already widely implemented. This principle has guided the
internet RFC process; https://tools.ietf.org/html/rfc2026 ("The Internet
Standards Process") is quite clear about it.

This does not in any way mean that the massive amount of work done on
the data structures and other libraries in R7RS-large is ill-advised or
wasteful. I simply don't believe that RnRS (and to a lesser extent SRFI)
are right vehicles for carrying it and formalizing it. There are many
indicators of this: the inability to establish a schedule and stick to
deadlines; the unclear scope; disagreement among WG members on both the
content of the standard and the process used to make it. All of these
are indicators of exploratory rather than scholarly work.

It's important to emphasize that there is nothing inherently wrong with
disagreeing, taking a long time, and working in fits and spurts, but I
think a standard should be more like a scholarly work that goes smoothly
on a set schedule like a train. Predictability and lack of surprises are
good ways to establish agreement; the design work involved in RnRS
should focus on tweaking things that are already widely implemented.

That's why I suggest that we keep all the high quality work that has
gone into R7RS-large, and continue expanding it, but find another
process to host it, a process that is built from the start to be an
ideal vehicle for exploration rather than scholarship and refinement.

If such a process enjoyed a similar de facto standard status as RnRS and
SRFI, the libraries being made by that process would have the kind of
high visibility and status that would help them be widely adopted over
time. The key would be to build a default place for exploratory work in
Scheme, and to invest schemers with ownership of that place so that it
is well kept. SRFI and RnRS both involve de facto ownership of specs,
and hence the specs are very well kept, but if we use these processes as
intended the barrier to entry is prohibitive for exploratory work.