Toward R7RS-large

[amirouche]

R7RS-small is part of Gambit repository in lib/scheme directory.

Here is the R7RS-large libraries:

R7RS	SRFI	Code	Tests	Doc	Review	Comment
scheme bitwise	151	❓	❓	❓	❓	❓
scheme box	111	❓	❓	❓	❓	❓
scheme bytevector	R6RS bytevectors	❓	❓	❓	❓	❓
scheme charset	14	✔️	❓	❓	❓	❓
scheme comparator	128	❓	❓	❓	❓	❓
scheme division	141	❓	❓	❓	❓	❓
scheme ephemeron	124	❓	❓	❓	❓	❓
scheme fixnum	143	❓	❓	❓	❓	❓
scheme flonum	144	❓	❓	❓	❓	❓
scheme generator	158	❓	❓	❓	❓	❓
scheme hash-table	125	❓	❓	❓	❓	❓
scheme idque	134	❓	❓	❓	❓	❓
scheme ilist	116	❓	❓	❓	❓	❓
scheme list-queue	117	❓	❓	❓	❓	❓
scheme list	1	❓	❓	❓	❓	❓
scheme lseq	127	❓	❓	❓	❓	❓
scheme mapping	146	❓	❓	❓	❓	❓
scheme mapping hash	146	❓	❓	❓	❓	❓
scheme regex	115	❓	❓	❓	❓	❓
scheme rlist	101	❓	❓	❓	❓	❓
scheme set	113	❓	❓	❓	❓	❓
scheme show	159	❓	❓	❓	❓	still draft
scheme sort	132	✔️	✔️	✔️	✔️	part of gambit
scheme stream	41	❓	❓	❓	❓	❓
scheme text	135	❓	❓	❓	❓	❓
scheme vector @	160	❓	❓	❓	❓	❓
scheme vector	133	❓	❓	❓	❓	❓

[lassik]

* scheme bytevector: rnrs bytevectors:

Is this the R6RS bytevector library?

[amirouche]

Le lun. 4 nov. 2019 à 08:50, Lassi Kortela <[email protected]> a écrit :

* scheme bytevector: rnrs bytevectors: Is this the R6RS bytevector library?

Yes.

[lassik]

@amirouche Do you know whether some of those R7RS-large libraries are more stable than others (API-wise)? I'm not familiar with -large yet. If some of the APIs still change a lot, we could start with the more stable ones.

[amirouche]

`scheme show` is still draft at https://srfi.schemers.org/srfi-166/. There is always a chance that a future docket will replace or change things. For instance srfi-128 (scheme comparator) was updated with more stuff by https://srfi.schemers.org/srfi-162/. Also there is a module that was replaced by another in the latest docket but I don't remember which one. I am in at least for those required by SRFI-168 that is the following: - scheme comparator (128 and 162) - scheme mapping and scheme mapping hash (146) - hooks (173) - scheme generator and accumulator (158) - scheme bitwise (151) scheme stream (41) is rather standard and used in many other scheme implementation (it is fair to say that it will not change). Similarly with scheme charset (14). Even if an update is somewhat planned, several scheme rely on it. scheme sort (132) is IIRC a slight update of a previous SRFI that is in Gambit? I never touched scheme text (https://srfi.schemers.org/srfi-135/ aka. immutable strings). I mention it because it will be very useful. Also skim over https://github.com/amirouche/arew-scheme/blob/master/arew-scheme.pdf to have an idea of what is in R7RS-large. By the way we can re-use the sources of that documentation, mostly extracted from SRFI documents and reworked to have is a single section for each form (except a few exceptions like scheme r5rs and scheme cxr). Many SRFI depends on scheme comparator (128 and 162), so it is good to start with this one.

[lassik]

All of that is very useful info - thanks! The arew doc approach sounds good.

I guess there is no harm in including even the less stable libraries, if someone is willing to do that work :) Perhaps they should be left out of base Gambit and be an optional add-on library. Perhaps in a separate github.com/gambit/r7rs-large repo?

[amirouche]

I guess there is no harm in including even the less stable libraries, if someone is willing to do that work :)

Yes :) Perhaps they should be left out of base Gambit and be an optional add-on

library. Perhaps in a separate github.com/gambit/r7rs-large repo?

The situation is tricky. Gerbil already started shipping r7rs-large as-is. So, there is three way: 1) Only keep SRFI in this repository and have a r7rs-large repo that will always be up-to-date to latest docket. And provide a deprecation mechanism? 2) put R7RS libraries (scheme fu) in this repo, along SRFIs. And provide a deprecation mechanism? 3) Do not provide (scheme fu) bindings until R7RS-large is done. By the way, (scheme fu) libraries are SRFI libraries that are re-exported under a different name. Except (rnrs bytevector) which comes from R6RS. Yeah, that is probably the best thing to do to be able to release Gambit before R7RS-large is done. Provide (scheme fu) bindings as a separate repository. scheme hash-table already comes with some legacy and a deprecation warning. Maybe we can extract that into a `(scheme version)` or `(scheme _version)` library and re-use it later? Also SRFI-145 (https://srfi.schemers.org/srfi-145/ aka. assume) is used in several SRFI but is not part of R7RS-large.

[lassik]

2. put R7RS libraries (scheme fu) in this repo, along SRFIs. And provide a deprecation mechanism?

I would vote for this option :) Since R7RS-large is clearly defined as its own separate entity, developed according to its own schedule, it's clearest if it has its own separate repo.

The finalized SRFIs that are part of R7RS-large, but also useful in themselves, could be included in Gambit's main repo if @feeley thinks they are useful enough; otherwise as add-ons? If they have both (srfi nnn) and (scheme aaa) import names, the (srfi nnn) ones could be in Gambit's main repo; the R7RS-large repo could provide the (scheme aaa) aliases for them. Opinions?

Also SRFI-145 (https://srfi.schemers.org/srfi-145/ aka. assume) is used in several SRFI but is not part of R7RS-large.

If it's easy to add to Gambit, we could add it to this libs repo right away.

[lassik]

The list of SRFIs in the README of this libs repo is just a suggestion for starting with the most popular ones; if others are useful, why not have those as well.

FWIW, Chicken implements a ton of SRFIs (perhaps more than any other Scheme implementation) but most of them are optional add-ons ("eggs"). The core has only a few essentials such as hash-tables.