Should index.scheme.org be changed to be a static site? Arvydas Silanskas (01 Jun 2024 15:25 UTC)
Re: Should index.scheme.org be changed to be a static site? Arthur A. Gleckler (01 Jun 2024 15:30 UTC)
Re: Should index.scheme.org be changed to be a static site? Arvydas Silanskas (01 Jun 2024 16:44 UTC)
Re: Should index.scheme.org be changed to be a static site? Arthur A. Gleckler (01 Jun 2024 17:14 UTC)
Re: Should index.scheme.org be changed to be a static site? Arthur A. Gleckler (01 Jun 2024 17:39 UTC)
Re: Should index.scheme.org be changed to be a static site? Lassi Kortela (02 Jun 2024 17:15 UTC)
(missing)
Types and documentation Lassi Kortela (02 Jun 2024 18:15 UTC)
Re: Types and documentation Arvydas Silanskas (03 Jun 2024 06:30 UTC)
Re: Types and documentation Lassi Kortela (03 Jun 2024 08:00 UTC)
Re: Types and documentation Lassi Kortela (12 Jun 2024 09:22 UTC)
Re: Types and documentation Arvydas Silanskas (12 Jun 2024 19:36 UTC)
Re: Should index.scheme.org be changed to be a static site? Arvydas Silanskas (15 Jul 2024 19:17 UTC)

Types and documentation Lassi Kortela 02 Jun 2024 18:15 UTC

> sources were already sexprs from the start, I too thought it was an
> obvious scheme-native text format choice (and I didn't intend to change
> it; the sqlite db I initially mentioned I meant would be generated from
> those primary sexpr sources). Perhaps I wasn't too clear previously, but
> those sexprs were always supposed to be the main thing of the project.

Good thinking.

> If you think they should explicitly live in a separate repository to
> accentuate that, that's fine by me.

I intend to start a project to write static types for RnRS and SRFI
procedures. As a dynamic language, there isn't one obviously correct
choice of static type system. So I'd like to write the signatures for a
few different type systems. I'm pretty sure the comparison would make us
learn something valuable.

Since you have already written types using one system, it would be
natural to add types written for other systems next to the ones you
already have. This assuming you don't consider it a burden.

Another project I think should exist, but haven't started, is a RnRS and
SRFI documentation project. Since RnRS and SRFI are written primarily as
implementer specifications, they are not ideal as end-user
documentation. We should write one set of user-friendly documentation as
a community, written in English with consistent grammar and style.
Scheme implementations could then copy from that documentation into
their manuals if they want.

Here too, you have already put together some documentation for
index.scheme.org. It would be a good starting point.

I'm not sure whether types and documentation should live in the same
repo and the same source files. My hunch is that the two projects would
work with a somewhat different format and cadence, and therefore would
be best separated. But would it burden your work to have two sets of
source files?