Unmaintained implementations
Antero Mejr
(13 May 2024 14:25 UTC)
|
Re: Unmaintained implementations
Arthur A. Gleckler
(13 May 2024 14:39 UTC)
|
Re: Unmaintained implementations
Lassi Kortela
(13 May 2024 15:17 UTC)
|
Re: Unmaintained implementations
Lassi Kortela
(13 May 2024 17:46 UTC)
|
Re: Unmaintained implementations
Antero Mejr
(13 May 2024 18:05 UTC)
|
Categorizing and describing implementations
Lassi Kortela
(13 May 2024 18:24 UTC)
|
Re: Categorizing and describing implementations
Jakub T. Jankiewicz
(13 May 2024 20:16 UTC)
|
Re: Categorizing and describing implementations
Arthur A. Gleckler
(13 May 2024 20:23 UTC)
|
Re: Categorizing and describing implementations
Lassi Kortela
(13 May 2024 20:37 UTC)
|
Re: Categorizing and describing implementations
Arthur A. Gleckler
(13 May 2024 20:39 UTC)
|
Re: Categorizing and describing implementations
Jakub T. Jankiewicz
(13 May 2024 21:19 UTC)
|
Re: Categorizing and describing implementations
Arthur A. Gleckler
(13 May 2024 21:26 UTC)
|
Containers
Lassi Kortela
(13 May 2024 21:37 UTC)
|
Re: Containers
Arthur A. Gleckler
(13 May 2024 21:41 UTC)
|
Re: Categorizing and describing implementations
John Cowan
(13 May 2024 21:51 UTC)
|
Re: Categorizing and describing implementations
Stephen De Gabrielle
(14 May 2024 08:23 UTC)
|
Re: Categorizing and describing implementations
Jakub T. Jankiewicz
(14 May 2024 11:55 UTC)
|
Snap and Lisp
Lassi Kortela
(14 May 2024 12:15 UTC)
|
Re: Snap and Lisp
Stephen De Gabrielle
(14 May 2024 12:45 UTC)
|
Re: Snap and Lisp
Lassi Kortela
(14 May 2024 13:33 UTC)
|
Re: Categorizing and describing implementations
Marc Feeley
(14 May 2024 12:48 UTC)
|
Re: Categorizing and describing implementations
Stephen De Gabrielle
(14 May 2024 13:09 UTC)
|
Re: Categorizing and describing implementations
Marc Feeley
(14 May 2024 13:29 UTC)
|
Re: Categorizing and describing implementations Jakub T. Jankiewicz (14 May 2024 14:03 UTC)
|
Re: Categorizing and describing implementations
Stephen De Gabrielle
(14 May 2024 17:45 UTC)
|
Re: Categorizing and describing implementations
Lassi Kortela
(19 May 2024 13:47 UTC)
|
Re: Categorizing and describing implementations
Antero Mejr
(20 May 2024 14:03 UTC)
|
Re: Categorizing and describing implementations
Arthur A. Gleckler
(20 May 2024 14:24 UTC)
|
Definition of "Scheme"
Lassi Kortela
(14 May 2024 13:21 UTC)
|
Re: Categorizing and describing implementations
Jakub T. Jankiewicz
(14 May 2024 13:53 UTC)
|
Re: Unmaintained implementations
Arthur A. Gleckler
(13 May 2024 19:12 UTC)
|
Re: Unmaintained implementations
Jakub T. Jankiewicz
(13 May 2024 20:40 UTC)
|
Re: Unmaintained implementations
Arthur A. Gleckler
(13 May 2024 20:43 UTC)
|
Re: Unmaintained implementations
Lassi Kortela
(13 May 2024 20:49 UTC)
|
Re: Unmaintained implementations
Arthur A. Gleckler
(13 May 2024 20:55 UTC)
|
Re: Unmaintained implementations
Lassi Kortela
(13 May 2024 21:07 UTC)
|
Re: Unmaintained implementations
Antero Mejr
(13 May 2024 21:18 UTC)
|
Metadata files
Lassi Kortela
(13 May 2024 21:34 UTC)
|
Re: Metadata files
Antero Mejr
(13 May 2024 21:41 UTC)
|
I think we can include table like this one: https://web.scheme.org/ But larger with more essential Scheme features, and those that implement more of them will be on top. More mature Scheme implementation will most likely implement all the features. For some people the features will not matter. Only the language of implementation and where it runs. For some they will pick the one that implement most of the features. We can do something like Wikipedia does for parser generators: https://en.wikipedia.org/wiki/Comparison_of_parser_generators we can indicate the supported feature with green and not supported with red and partial with yellow. On Tue, 14 May 2024 15:29:12 +0200 Marc Feeley <xxxxxx@iro.umontreal.ca> wrote: > I am not arguing to exclude TinyScheme and SIOD from get.scheme.org > <http://scheme.org/> . My point is simply to assign a strict meaning to the > label “implementation of Scheme”. > > The get.scheme.org <http://get.scheme.org/> page should be organized as a > table that gives for each implementation of Scheme (and variants) which > features of the RnRS they support (and perhaps to what extent). I remember > seeing a page for this (is it somewhere on scheme.org > <http://scheme.org/>?). The current get.scheme.org <http://get.scheme.org/> > page is somewhat like that already with labels for each RnRS supported, so > some implementations could have no label, or perhaps a “low” score in the > column corresponding to the closest standard. > > There could also be two sections. The first is for RnRS conformant Scheme > implementations and the other for “partial implementations of Scheme”. > > That way, people new to the site will have a rough idea of what they are > getting into when they get a specific implementation. > > Marc > > > > > On May 14, 2024, at 3:09 PM, Stephen De Gabrielle > > <xxxxxx@gmail.com> wrote: > > > > I feel we are poorer - and doing potential schemers a disservice - if we > > continue to exclude TinyScheme and SIOD from https://get.scheme.org > > because, TinyScheme only does a subset of R5RS, and SIOD only Implements > > the scheme from the Lambda Papers. > > > > Are we lawyers/philosophers/pedants arguing over definitions? > > or are we scheme enthusiasts who would like others to get the benefits > > we get when using(or implementing) a scheme for our applications? > > > > Best regards > > Stephen > > > > PS. In case I was not clear - the standards and SRFI information is > > essential - I am not suggesting we 'throw the baby out with the > > bathwater'. > > > > On Tue, May 14, 2024 at 1:48 PM Marc Feeley <xxxxxx@iro.umontreal.ca> > > wrote: I’m somewhat of a hardliner on the subject of what is required for > > a system to qualify as a “Scheme”, which for me means an implementation > > of the Scheme language. > > > > A “Scheme” should be defined as an implementation that conforms to one of > > the RnRS reports. Others should qualify as “Scheme subset”, or “Scheme > > like” implementations. I think we all agree that small deviations from an > > RnRS report are OK. But some features are essential, such as lexical > > scoping, proper tail-calls, and continuations. Just having parentheses > > and being simple does not qualify as “Scheme”. > > > > By the way, Ribbit would qualify as a Scheme since it fully conforms to > > R4RS. > > > > Marc > > > > > > > > > On May 14, 2024, at 1:55 PM, Jakub T. Jankiewicz (via schemeorg list) > > > <xxxxxx@srfi.schemers.org> wrote: > > > > > > On Tue, 14 May 2024 09:23:40 +0100 > > > Stephen De Gabrielle <xxxxxx@gmail.com> wrote: > > > > > >> I’m very tempted to try make a case for calling ‘Snap!’ a scheme > > >> dialect: https://snap.berkeley.edu (looks like another block > > >> programming clone of scratch, but has scheme capabilities like first > > >> class functions) > > > > > > Snap! may have similar semantic to Scheme but I would not call Scheme > > > a graphical/block language, it's not even lisp. The same JavaScript, R > > > or Ruby have lisp similarities but calling those languages lisp would > > > be overuse of the term. Some people call them lisp though. > > > > > >> > > >> Indicating if a scheme supports RnRS or SRFI’s is obviously very > > >> useful. > > >> > > >> Scheme is a living (and evolving) language with a passionate community > > >> in addition to implementation communities. Let’s not exclude any. > > >> > > > > > > -- > > > Jakub T. Jankiewicz, Senior Front-End Developer > > > https://jcubic.pl/me > > > https://lips.js.org > > > https://koduj.org > > > > > > > > > -- Jakub T. Jankiewicz, Senior Front-End Developer https://jcubic.pl/me https://lips.js.org https://koduj.org