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)
|
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:27 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)
|
> The smaller something is, the easier it is to add. But that's all. > > It's not too much hard work. But it won't be done unless an implementor > is willing, of course. The unfortunate thing about standards is that what wins is whatever succeeds at establishing agreement. > Many seasoned schemers dislike R6RS on aesthetic grounds to the extent > > I don't get why it could be disliked on aesthetic grounds. Probably just the scope of it, or the politics; I'm not experienced enough to know what the precise cause is, but it still ruffles feathers. > The Scheme community is split; there's no point in trying to cover it. It has been split for one third of its lifespan: about 15 years (give or take) out of 45. That's a lot, but the standard has been united twice as long as it's been split. We can unite it again. If R8RS unites R6RS and R7RS, the split will cease to have practical consequences and people will soon forget it. > What could work, is a standard that has everything from both R6RS and > R7RS-small combined, so that a Scheme implementation supporting all > features of the new standard will run all existing code from R3RS > upward. > > That would be great. It makes me very optimistic that you would support such a move! > R6RS is compatible with R5RS (to the extent it makes sense). It's hardly > irresponsible. Half of the community may see it as a bad standard but > that doesn't necessarily make it true. We come back to the unfortunate fact that successful standards establish agreement. R6RS is a successful language but an unsuccessful standard. I'm concerned that R7RS-large will meet the same fate. 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. Having options would be formalizing what Scheme implementations already do in practice anyway. No implementation supports all of R7RS, and John has mentioned that many or most of the R7RS-large libraries could be options. Scheme is also extremely well suited for subsetting; it would be nice if RnRS gave a nod to this. > I think the Python cleanup was good. But R6RS vs R5RS is not like Python > 3 vs Python 2. It would have been a good cleanup for a non-standard language. But the Python devs found out the hard way that Python 2 is a de facto standard that is not easily dethroned. 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. R7RS-large is done with the same mentality, but more measured. It's nice that the libraries are optional, but the next RnRS report has a moral obligation to carry all of the libraries that now go into it (they can be options, but they must still be there). No report should pass on a moral obligation for the next report to carry stuff that hasn't been proven and widely used in the field. Experimentation should be done via experimental design processes. > The harder part of syntax-case is the pattern matcher and hygiene. But > this is already what an R7RS-small (even an R5RS system) must ship anyway! I lack the expertise for this, but someone said psyntax (in its various forks) is basically the only extant syntax-case implementation, and only a small handful of people understand it.