Conformance: a bottom-up approach
Lassi Kortela
(14 May 2024 15:13 UTC)
|
Re: Conformance: a bottom-up approach
Antero Mejr
(14 May 2024 19:26 UTC)
|
Organization and tooling, etc. Lassi Kortela (14 May 2024 19:43 UTC)
|
Other Scheme domains
Lassi Kortela
(14 May 2024 19:58 UTC)
|
Re: Other Scheme domains
Antero Mejr
(14 May 2024 21:47 UTC)
|
Re: Other Scheme domains
Andrew Whatson
(15 May 2024 01:27 UTC)
|
PreScheme and scsh sites
Lassi Kortela
(15 May 2024 11:23 UTC)
|
Re: PreScheme and scsh sites
Andrew Whatson
(15 May 2024 15:20 UTC)
|
Re: PreScheme and scsh sites
Lassi Kortela
(15 May 2024 17:02 UTC)
|
> I like this idea. At the top level, there can be "gold standard" > implementations: those that comply closely to the R6/R7RS spec + the > most SRFIs, like Gauche and STklos. Great. I was also searching for a sports metaphor. Something about medals or leagues. IIRC Kawa only does escape continuations, and Gambit's hygienic macros are currently broken. MIT Scheme only just got R7RS support. So we need to put some work into the interpretation lest no implementation qualifies as Scheme :) > As a tangent, I think doing the work to maintain better documentation > may be more difficult than it needs to be, because the info is split > across 8+ repositories and 3 Github organizations (schemedoc, schemeorg, > schemeorg-community). Also, building the documentation requires having > many different Scheme implementations installed (like the srfi-metadata > table). > Do you think there would be value in a web infrastructure consolidation > to a single Github organization, and decide on a single Scheme > implementation to build it? The website (and Scheme documentation in > general) seems a bit fragmented/siloed. Oftentimes I need to switch > between the r7rs.org website, Gauche website, and SRFI website just to > write basic code. Yes. But if you explore the problem from multiple angles, you may find that putting everything in one repo or organization is trading some problems for other problems. schemeorg and schemeorg-community are separate because the former is meant to be a self-contained kernel for which we can always find committed maintainers (Explained in https://srfi-email.schemers.org/schemeorg/msg/15602174/) schemeorg-community is meant to be the consensus-driven parts of scheme.org, without commitment. schemedoc is an organization that predates the current scheme.org site and contains all kinds of stuff, not just for the site. The tools suck, that's for sure. They are an ad hoc patchwork that is being very slowly cleaned up. Help is welcome. Doing as much as possible in portable R7RS Scheme would make things easiest. https://www.scheme.org/source/ was just added as a first aid. I am in favor of making https://docs.scheme.org/ an all-purpose browser for hierarchical documentation, similar to https://devdocs.io/. IMHO it should contain the RnRS standards, implementation manuals, tutorials, books, library documentation - the works. License-wise we could have pretty good coverage. I'm not sure about the political aspect. Schemers are a disagreeable bunch and tend to distrust new things, so quite a bit of advocacy may be needed. If this is your vision, I support it.