Re: Request for feedback on SRFI-126

[taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)]

Arne Babenhauserheide <arne_bab@web.de> writes:

> [...] The best language for any job is the one which provides the
> solution off-the-shelf. SRFIs could give Scheme such solutions, and
> the flexibility of Scheme would allow making these solutions much more
> elegant than what can be created with Python.
>
> But someone has to actually do that: Creating libraries with
> consistent style which provide to the application developer what
> Scheme already provides to the language developer.

Exactly, I agree.  It should be noted though that some things can be
implemented purely as portable libraries, so there needn't be a Request
For Implementations to do it, whereas some other things, which I call
"fundamental" features, need to be supported by implementations, so they
need to be in the language specification or an authoritative SRFI.

For instance the "sets and bags" library in SRFI-113 could have been
just a library hosted on snow-fort.org or elsewhere because it can be
implemented as a library on top of hash tables, but the hash table
library/API needs to be in the language because it can't be implemented
as portable library code (not very well anyway; see SRFI-69 ref. impl.).
I like to think of SRFI-126 as "R7RS-small section 6.10 Hashtables" if
that isn't too shameless.  (I don't know yet if it's really worthy of
that, hence critique welcome.)

***

I think there are only few fundamental APIs left now that need to be
standardized, for standard Scheme to become fairly seriously usable and
possible to write as plenty libraries in as e.g. Python.  One could
already do a ton given R7RS-small, SRFI-99, SRFI-106, SRFI-115,
SRFI-126, though the mentioned SRFIs aren't well-supported yet.  After
that, we probably want a fuller POSIX API (not just sockets), an FFI,
delimited continuations, and a few other things.  Care needs to be taken
not to fall for API design mistakes in the conception of these SRFIs,
but I could say I see the writing of them as more drudgery than anything
else at this point.

But sadly, there seems to be little interest anymore among the biggest
Scheme implementations to help get that work done.

In any case I'll go on to write a delimited continuations SRFI inspired
by Guile's API, an FFI SRFI based on libffi's feature-set, will preach
for broader syntax-case adoption (don't know about phasing yet), and see
if I can write some POSIX API SRFIs as well.

If that effort will be in vain, so be it I guess.

Taylan