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

> Hello, John and Taylan.  SRFI 126 just went into final
> status, and I'm guessing that SRFI 125 be finished sometime
> soon, too.  Since both cover hash table APIs, and indeed
> since 126 was written specifically as an alternative to 125,
> it would be useful to compare them.
>
> After SRFI 125 goes into final status, would you each be
> willing to publish a message giving your design rationale
> with respect to the other SRFI?  There's nothing that says
> that both SRFI can't be provided by the same Scheme
> implementation, but it would be nice for implementors to
> hear "from the horse's mouth," so to speak, why each of you
> made the decisions you did.
>
> Thank you both.

Sure.  Let's see...  Consider this a draft; I can clean it up once
SRFI-125 is finalized.

When I started SRFI-126, I could see the following problems in SRFI-125,
which by the way seemed to reflect more general problems in the
direction that SRFIs intended for R7RS-large seemed to be taking:

- It specified an API that is incompatible with both previous standards
  for hash tables (SRFI-69 and R6RS).

- It was shying off of specifying features that cannot be implemented as
  portable library code for a large number of Scheme implementations
  (thus gravely limiting what can be specified).

- It was specifying a large number of utility forms (such as for bimaps)
  which would, in my opinion, be better placed in a de-facto-standard
  third-party library such that changes to it can be made more easily
  than to wait for the next RnRS.

Since then, SRFI-125 has changed significantly to address some of these
points.  At one point it was said that a merge might be possible, but I
think the differences were running too deep after all.  Going over the
current draft and reconsidering the three points above:

- It is now mostly compatible with SRFI-69, although it has the
  strangeness that make-hash-table is allowed to ignore its hash
  function argument in some circumstances.  One is also encouraged to
  use comparators, which are a big change from SRFI-69 and R6RS.

- No external representation is specified.  There is brief mention of
  implementation-dependent support for weakness, but it seems like an
  afterthought.

(- Utility forms seem to have been decreased drastically, so no
   complaint about that.)

Separate from those points, there is now the strangeness about the
arguments that should be passed to hash functions.  I don't know if a
resolution has been reached yet, but ultimately it seems that specifying
hash functions to simply take an object and nothing more is a perfectly
fine option, so the alternative considerations are just slowing us down
I think, if not doing any other harm.

SRFI-126 makes decisions that are fairly straightforward:

- SRFI-69 is demonstrated to contain a crucial flaw, so R6RS is taken as
  a basis, which is a perfectly fine basis really.

- Weak/ephemeral tables, external representation, and quasiquote
  semantics are specified in full.  They are technically optional to
  support so we don't entirely lose support of smaller implementations,
  but the intent is that there is pressure to implement them eventually.

- A healthy balance in the inclusion of utility forms is attempted, with
  halfway explicit criteria for inclusion.  (It's still pretty vague,
  admittedly.)

- Hash functions are Object -> Integer, full stop.

All that is the reflection of an ideology that might be summarized as
"stop standard-Scheme from being a joke as soon as possible."  (In the
eyes of people used to more mainstream languages.)  Not by entirely
giving up the notion of elegance of course; the intent is not to make
Scheme into Python 4.0, but to nudge it towards adopting more positive
attributes of languages like that, while still being Scheme.

By the way I'd like to remind that it was John himself who originally
encouraged me to start working on this SRFI.  I'm very thankful for
that, and there's no personal enmity involved in the whole ordeal, just
to make it clear to third parties.  (I sure could have mentioned this in
the Acknowledgments.  There's *always* something you remember after
finalization, isn't there?)

I'm also sad that we couldn't meet in the middle with Alex on hash
functions.  It was a difficult topic and I'm basically running to the
safe side by simply specifying Object -> Integer.  I hope it will prove
to be a fine choice in the long term.

Taylan