"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:

> Scheme Request for Implementation 125,
> "Intermediate hash tables,"
> by John Cowan and Will Clinger,
> is now available for discussion.
>
> Its draft and an archive of the ongoing discussion are available at
> http://srfi.schemers.org/srfi-125/.
>
> You can join the discussion of the draft by filling out the
> subscription form on that page.
>
> You can contribute a message to the discussion by sending it to
> srfi-125@srfi.schemers.org.

I would like to make an alternative proposal, whose first draft is for
now available here:

http://taylanub.github.io/doc/r7rs-hashtables.html

Can we put this up as SRFI-126?

In case anyone thinks this is some sort of petty move against SRFI-125,
no, we have been in contact with John Cowan and he encouraged me to push
out my counter-proposal and let the community decide what they prefer.

I'm also not confident at all of the quality of my proposal because I'm
not a very experienced Schemer.  I'm trying to offer an alternative
direction for R7RS-large because of the dismay against R7RS-large's
current direction I've seen in some people, but I don't know whether I'm
addressing those people's concerns well at all.

To give some basic ideas on the direction I have in mind: for instance,
not giving something like SRFI-114 such a central role, because I can't
be sure that it will have a bright future.  Keeping APIs somewhat more
conservative in general so as to make sure that we don't encode many
flaws into the standards which will be a burden for near eternity, and
so as to make sure we don't burden developers with the maintenance of
many procedures which are very seldom used except by those who like to
write "exciting" code.  (I think source code needs to be "boring" to
some degree to make it easier and safer to work with it.  Fancy
constructs should be kept for when they're *necessary*.)

If there are any procedures in SRFI-125 which, if they were missing, you
*know* you will be defining them as helpers in many of your projects,
then please point them out so I can add them to my proposal.  So far the
API is fairly minimal (although less so than R6RS), not because of a
dogmatic following of minimalism but because of the above mentioned
concerns that are rooted in pragmatism.

For instance, alist->hashtable is a given, but how often do you really
use hashtable->alist?  How often will you really be using hash-table-map
or a variant thereof instead of choosing a more manual route via
hash-table-for-each or such because your use case is close but doesn't
exactly correspond to the semantics of hash-table-map?  (These are
genuine questions, not suggestions that the mentioned procedures in
particular are useless.)

Kind regards,
Taylan