is now available for discussion.
You can join the discussion of the draft by filling out the subscription form on that page.
The author announced this SRFI on the SRFI-125 mailing list with this introduction:
I would like to make an alternative proposal, whose first draft is for now available here:
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