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: Interaction between spec and code Lassi Kortela 30 Apr 2021 14:56 UTC

> Per is committed to a classical OO implementation of Scheme, so of
> course monomorphism seems just an annoyance to him.  But I concluded a
> decade ago that there will never be a consensus on the One True OO
> System (which is why I have ruled out standardizing any of them in
> R7RS-large (modulo an appeal)), and still less on the One True Class
> Hier/Heterarchy.  As long as the names are kept as consistent as
> possible, I don't think having lots of them is a burden on the mind,
> though it may be a burden on the fingers.  In addition, fast-generics
> from Chicken and particular typeclasses should help.

You made the right call IMHO.

>         I wouldn't suggest splitting this collection. It just has to be
>         anarchic enough so that there is no bias towards certain idioms.
>
> Well, let us say, to minimize bias.  One of the reasons for having so
> many SRFIs with the same procedures over and over is to help with the
> problem of "Oh, data structure X is perfect for what I want to do, but
> it has so few (or no) procedures (that I would have to write myself)
> that I'll just use lists instead, which have lots of procedures."

It's true that a large language should have lots of convenience
procedures (Mathematica is probably the most extreme example of this).

But unless I misunderstood him, Marc was making a different, orthogonal
point: that there should be a separation between "core" procedures that
are required for an efficient and portable implementation of the
functionality, and "convenience" procedures that can be implemented
fully in portable code by relying on the not-efficiently-portable
"core". The convenience procedures are much more subject to taste than
the core ones, so they could benefit from a different release process,
with possibly more than one group working on a user-friendly "skin" on
the core stuff.

For example, there could be a monomorphic skin with different procedures
for each data structurem and another OO-style polymorphic skin such as
Kawa would like. Also a functional skin and an imperative skin, etc.

If SRFIs dealt mainly with the core stuff, the design work involved
ought to be less controversial (e.g. the things required to implement an
efficient data structure can be figured out from CS textbooks and
studying known performance characteristics of different virtual
machines) and we'd arrive at a minimal portable API on top of which
other projects could build.