John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> >From what I can tell, SRFI-69 is obsoleted by the R6RS hashtable API.
>
> I think that's an exaggeration.  As far as I know, Chibi, Chicken, and
> Husk support SRFI 69 but not R6RS hashtables, and Gauche's native hash
> tables are close to SRFI 69.  Among R5RS implementations, SISC, STklos,
> and even SigScheme support SRFI 69.  That's a fairly substantial presence.

An implementation that supports SRFI-69 and R7RS also supports R6RS
hashtables thanks to the (r6rs hashtables) library.

An implementation that supports neither R6RS hashtables directly nor
the R7RS feature-set is in dire need of modernization.

> In addition, I intend to propose a new hash table SRFI, available in
> pre-SRFI form as <http://trac.sacrideo.us/wg/wiki/HashTablesCowan>,
> which is much closer to SRFI 69 than to R6RS.  (Note that the
> Implementation section is obsolete now that Will Clinger has written
> a full implementation of it, which uses R6RS if available and SRFI 69 if not.)

I think we discussed that one before, but I have serious problems with
that one:

- It extends neither SRFI-69 nor R6RS hashtables; it's something new
  entirely.  What the heck?

- It regresses from R6RS hashtables in that keys aren't allowed to be
  mutated, even if it's a eq?/eqv? table.  A totally needless limitation
  that prevents a whole class of use-cases of hashtables which is to
  create *arbitrary* object associations.

- It standardizes a *ton* of utility functions, and the bimap type, yet
  no weak tables support is standardized.

Pretty please, take the R6RS API, add rudimentary weakness support (just
a couple new constructors and predicates?) and be done with it.  I would
have thought that's the most obvious next step from R6RS hashtables.

And if not that, then adopt R6RS hashtables as-is into R7RS please!
After all, there is already (r6rs hashtables) which makes that API
available on all R7RS systems.  This means "SRFI-69 is more widely
supported" is not an excuse.

All those utility functions can be made into a library outside the
standardization process, which would become a de-facto standard if
people like it.  Same with bimaps (unless they cannot be implemented
purely as a library).  The whole effort to standardize these as a part
of Scheme is huge amounts of wasted effort and contains dangers of
standardization accidents that will diminish the credibility of the RnRS
*even* further.

I love some of your contributions, but that page makes me panic.

Sorry for going off-topic, and perhaps being very opinionated on this
one.

Taylan