Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Hello Guile folks,

I've made pretty fine experiences with R7RS-small so far[0][1][2][3],
and after seeing people's disdain towards R7RS-large's direction and
agreeing with them (although I wouldn't trust my own judgment alone),
I've decided to try pushing R7RS-large in a somewhat better direction.

The benefit for Guile?  I shortly summed up my thoughts on that in the
FOSDEM thread on the Guix ML; here the mail from the archives:
http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00759.html

Perhaps a better summary: better Scheme standards -> more libraries that
work on any implementation -> more total Scheme users & more free-flow
of users between implementations -> more potential for growth of the
Guile community.  Not to mention simply more libraries Guile users can
use, from the pool of standard-Scheme libraries, without needing a Guile
porter and maintainer for every possible Scheme library.

The envisioned direction for R7RS-large?  I'll try writing specs which
could have been part of the clean R7RS-small, or could be part of an
R8RS that would be more in the vein of R6RS (without some key bad
parts), that is: not being overly minimalist, not catering to obscure
implementations that are barely maintained and used, being more daring
in requesting modern and advanced features from implementations that
want to be compliant.

Not like R7RS-large's apparent current direction[4][5][6][7][8], i.e.:
specifying a ton of questionable libraries that seem to fill imaginary
gaps, invite design bugs through the inclusion of spurious utility
forms, and overall seem more suitable to live as third-party libraries,
because they can be implemented as such without needing support for
additional fundamental features from Scheme implementations.  All the
while said fundamental features are neglected from standardization
because X and Y minimalist implementation of Scheme won't be able to
support them.

Does that make sense?  Feel free to add to this high-level description
of the desired direction, even if it seems vague.  I'm trying to sum up
the sentiment of others, so don't see the above as my personal opinion.

I'm doing my best to bring together good ideas from mature Scheme
implementations like Racket, MIT/GNU Scheme, Gauche, and it goes without
saying Guile.  I shamelessly bother people like Taylor Campbell and Mark
for their input, feeling they have a good sense for API design, get
input from Shiro Kawai (Gauche author) and others on the SRFI MLs (John
Cowan also has pretty good ideas sometimes), bother 'samth' and
'stamourv' on #racket, Jorgen Schäfer ('forcer') on #emacs, and so on,
overall trying to work as an aggregator of good ideas.

I hope that clarifies why/how someone inexperienced like me could be
working on SRFIs/R7RS-large.

***

Now on to SRFI-126.

http://srfi.schemers.org/srfi-126/

First, why?

Short history: there is SRFI-69, and it sadly has a design bug that
makes it unsuitable for Schemes with a moving garbage collector (the "by
pointer identity" hash function is exposed).

Then there is the R6RS hashtables API, which is a good base and indeed
SRFI-126 builds on that, fully backwards compatibly.  Indeed I would
have said "just standardize R6RS hashtables for R7RS" if it weren't for
SRFI-125 popping up and gaining traction.  It was a third incompatible
API, not compatible with either SRFI-69 nor R6RS.  Terrible!

I needed to steal the attention from SRFI-125, so to say, with something
that offers similarly neat features missing in SRFI-69 and R6RS, but
without being terribly incompatible with them.

Since then SRFI-125 received big changes and became SRFI-69 compatible
itself, somehow managing to amend SRFI-69's design bug.  If it also
drops the SRFI-114 dependency and gets a little more polish, we might
actually merge SRFI-125 and SRFI-126, but that hasn't happened yet.

So I would now love to get feedback on the SRFI from the whole Guile
community.  Do you think it's RnRS worthy, specifically could it have
been section "6.10 Hashtables" in R7RS-small?  Would you enjoy being
able to use the library in your Guile programs?

I would especially love hearing the thoughts of the other main Guile
developers, since I only queried Mark so far.  Of course, I know you're
all very busy, and I think I understand the frustrations over the RnRS,
so no problem if you have no time or just don't feel like it.

***

After that?

I will probably work on a delimited continuations SRFI, heavily inspired
by Guile's call-with-prompt, since I find it *immensely* more easy to
grok than shift/reset and prompt/control because those mingle together
the "stack slice" and the "handler" code whereas call-with-prompt
clearly separates them.

I will probably push for syntax-case re-standardization because it's
very powerful and IMO most correctly captures/reifies the notion of
Scheme "identifiers" as separate entities from contextless symbols.

I will probably push for SRFI-99 standardization because it's backwards
compatible with our beloved SRFI-9 and removes other flaws of R6RS
records, while adding the important fundamental feature of subtyping.
Like R6RS it also allows non-hygienic creation of getter/setter
procedures, which seem often desired.  (I wish it also supported R6RS's
"protocol" feature...  While seeming obscure, it has no clean
implementation without being supported as a fundamental feature.)

Let's see where this goes...

I hope I didn't waste your time and am only wasting my own at worst!

Taylan


[0] https://github.com/taylanub/scheme-srfis
[1] https://github.com/taylanub/scheme-bytestructures
[2] https://github.com/larcenists/larceny/tree/master/tools/R6RS
[3] https://github.com/TaylanUB/srfi-123 (code in srfi/ dir)

[4] http://srfi.schemers.org/srfi-114/ "Comparators"
[5] http://srfi.schemers.org/srfi-113/ Sets and bags using "comparators"
[6] http://srfi.schemers.org/srfi-116/ Separate "immutable pair" type
[7] http://srfi.schemers.org/srfi-117/ Queues based on lists
[8] http://srfi.schemers.org/srfi-125/ Hash-tables using "comparators"