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 Amirouche Boubekki 01 May 2021 16:43 UTC

> If we standardize existing work

I am ok with that.

> then individual implementations
> can try different approaches to things like threads, and if a consensus
> emerges among them, then that consensus can be written up in RnRS.

Ok

> > What would be the advantage of moving to R8RS?
>
> Putting the R6 vs R7 split behind us.

I do not understand why R8RS output will solve that problem, that R7RS
can not. Except increment a number.

> IMHO RnRS is no longer a good primary vehicle for driving educational
> values.

I disagree.

Both R7RS and SRFI social processes and technical outputs are driving
educational values, whether it is initial education or improving or
increasing or perfecting existing knowledge. Compare that with Python
or even worse JavaScript: Python, mainly CPython community drive the
language, it is open to some extent but less welcoming than Rust (for
various reasons, among other things almost nobody is paid to do it),
JavaScript is on one side a complete fragmented chaos (that is where I
learned about the concept of "code pollution"), and good luck trying
to voice your concerns about ES spec, whether it is on github or on
W3C mailing list. More about W3C, I am still subscribed to two mailing
lists: wasm and RDF. WASM ML is completely silent, same with both
freenode and mozilla channels. RDF is an ivory tower of highly
educated PhDs [0].

Regarding "initial education", except maybe scratch visual programming
language, without picking a particular Scheme, R7RS is in a better
position than any other programming language that I know.

[0] https://github.com/w3c/EasierRDF/issues/79

> R6RS is still very beautiful compared to most programming
> languages, but many parts are far from the jewel that R5RS is.

I need to read a second time R5RS with a particular attention to that.

Speaking of R5RS, I was going to suggest R7RS-micro without the library system.

> > As far as portability goes, it is possible across R6RS and R7RS. Tho,
> > a test suite that is not normative, and easy to re-use will help a
> > lot.
>
> The details are inconvenient enough to cause problems with everyday
> work, and they are not on track to be fixed since RnRS has been and is
> caught up with pursuing its creators' vision.

I do not understand the last part of the sentence "and they are not..."

It is possible to write portable code. What is not possible is picking
a random program and running it on any Scheme.

> True. Some implementations have good traction on their own. But it makes
> sense to study why the portable Scheme doesn't get some of it.

The problem is not the standard but the lack of interest and the lack of users.

> It's clear we
> can't standardize things fast enough in RnRS to support all that work,
> and I think we should give up on the ambition to do that.

If R8RS gives up on portability, what will be the point of R8RS then?

Side notes, unrelated to the topic:

> If we start out pursuing a solid spec for threads

AFAIK, there is not much difference between the various threads API,
there is among several Scheme a denominator around POSIX thread
interface that has an SRFI. It seems to me there is no agreement on
whether threads are cooperative, or can be pre-empted, and whether
they run truly in parallel (different CPU cores) or not, and how to
communicate with the threads. Even if I was / am die-hard Chez user, I
do not know whether threads are necessary in the standard.

> or FFI and won't rest before we are done, we'll be exhausted and unhappy.

Again side note unrelated to the core of the topic: There is existing
work. It is possible to create DSL to interop with the host, and fine
tune the details, until it is good to be standardized. I am not
suggesting I will do the work, just that there is a way to make
progress on the subject.

>
> >> And adding new people to the community is hard if no-one can figure out
> > which of the warring RnRS, if any, is legitimate.
> >
> > Nobody cares (meme https://i.redd.it/b9ca0ux5wkq41.jpg). My
> > understanding there is three reasons to take part in SRFI / RnRS:
> >
> > - Improve / communicate / gather software engineering practices and
> > have a conversation with knowledgeable people
> >
> > - Grow your audience to attract users in to your implementation,
> > possibly aiming for Turing award or such
> >
> > - Have feedback on your own ideas
>
> RnRS is like the World Cup of design rigor. A team will be exhausted if
> every game they play all year round is a World Cup game.
> This is in fact what we are now seeing among RnRS contributors.

If it is an argument about scheme-live, then I agree. IMO scheme-live
does not call for R8RS.

>
> > None is Scheme specific. And forking the language and target JS or
> > wasm has a much bigger chance of success (including much more industry
> > adoption). What remains is "Scheme spirit" which I keep repeating is
> > according to me: aiming for perfection, and that leaves too much to
> > interpretation to guide any standardization work.

> If you pick a particular vision of perfection and drive it in RnRS, the
> next RnRS group will disagree and pick a different vision. It seems
> self-evident that the process is leading nowhere and is hurting Scheme's
> user community. If things keep going as they now do, there's no reason
> to believe that a future R8RS group will pick a vision compatible with
> the R6RS group or the R7RS-large group.
> They'll invent a third vision.

Then be it.

To keep it short, I think we agree on the scheme-live project, but we
disagree on how to proceed about the social and technical aspect of
scheme-live project. If I reply to future messages, I will do it
privately and I recommend you do the same.