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
Lassi Kortela
(25 Apr 2021 20:29 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)
|
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
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)
|
> > It is also a technical issue, the Scheme world is so diverse in terms > > of implementations and goals that it is difficult to contribute to > > Scheme without a dedicated Scheme implementation for the purpose of > > the SRFI process and RnRS. > > It is, but a big collection of working code would also motivate porting > work. If I understand correctly, SRFI / RnRS libraries would be collectively owned by participants including maintainers of Scheme implementations that want to take part in the process? The alternative at the moment is to copy and tweak sample implementations or create an implementation from scratch. > Unit testing and CI could be solved in one place, especially if we > use a monorepo. I agree. > Then adding tests for any new code can immediately use > the work that has gone into those tools, and for portability there are > lots of existing cond-expand's to use as examples for how to do it. As far as I know cond-expand is not trivial to implement. And even if it was, it will not completely eliminate the problem that some Scheme may want to use a completely different implementation that will force us to have cond-expand based on implementations. > > A sample implementation of Scheme and SRFI would be awesome but I assume > it's too difficult to pull off, unless an existing implementation is > gradually turned into the sample implementation by adding features. > As far as I know there is no Scheme implementation that can run on a trivial subset of Scheme (that is maximally portable across Scheme implementations and Operating Systems), and that is easy to debug (breakpoints, step debugger, variable inspection, one step macro expansion). Including a garbage collector is too much work (I am clueless about the subject). Regarding things like threads, network or SRFI-170, it could be emulated (a portable C FFI can be a very useful addition :). > >> Would the people around SRFI be interested in formalizing the > >> lightweight work we already more or less have? > > > I do not understand the question. What needs formalization? > > Really just blessing a monorepo with "official" status. The community is > already doing work like this, but it's split into many libraries around > the net, with different people working on each library. If we had one > library that is known as a canonical one, with many people working on it > (roughly, the people now writing SRFIs, plus anyone else who wants to > join) people would slowly learn to trust it. I agree. I still wonder whether being portable like the projects below is not more work than the alternative I describe above. One drawback of relying a lot on external implementations, is that if the maintainer goes, scheme-live will end-up with debt code or we will need to decide to drop support for that implementation, which is a difficult choice. Also I support your approach to request some formal acknowledgement for this monorepo: the projects you mentioned below have tried to reach an informal consensus, but did not succeed, it can be improved and that is not wasted effort. scheme-live can probably re-use some of those libraries. > The library collections like Schemepunk, Yuni, Spells, Spheres, etc. are > especially interesting as prior art. These are like Scheme Live, but > tend to have one maintainer who stops working on it after a few years. > Ideally we could roll all of them into one collection with enough people > to ensure continued maintenance. Those are great projects. Also it shows there is a strong interest about the subject.