[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reasons for withdrawal

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

At Tue, 28 Oct 2003 14:35:15 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> In an attempt to break this circular flame war, please state your 
> objections in a point by point matter, citing evidence.

First I'd like to retract my previous comment on dictionaries.  After
discussing with Scott on IRC I found there is no actual make-dictionary
procedure or concrete dictionary type, so those comments are irrelevant
until such time as a hash/av-tree dictionary is realized.

However, that was when I first truly grasped that this is purely a
meta-SRFI, and relies entirely on future work to be useful.  Although
SRFI-35, for example, was designed with the intent for future expansion
(SRFI-36), it is encapsulated and usable in and of itself.  Moreover,
the method of expansion is concretely laid out and a reference
implementation given in portable Scheme.  From this I see two problems
with SRFI-44 (specific interface issues aside, I think it's too late to
bring them up if they weren't mentioned earlier):

  1) SRFI-44 is not self-contained, and not expandable in a portable
     fashion.  I agree with the others that TinyCLOS is not an
     acceptable pre-requisite.  SRFI-44, despite the fact that the
     document never mentions it, is an API presuming a polymorphic OO
     system, and attempts at implementation outside such a system would
     be worthless.  An OO SRFI is a pre-requisite to this style of API.

  2) SRFI-44 is acting as an Oracle.  It presumes to know in advance the
     best API for all collections and dictionaries, without having
     nailed down or even explored those individual areas.  There is a
     *huge* amount of variation and discussion waiting to happen on such
     individual primitive API's as hash tables, heaps and trees, and
     from those usage as sets, dictionaries, priority queues, etc.
     While in the end an API not unlike SRFI-44 may in fact be the best
     suited to unification of those data-types, I think we need to lay
     the foundation before we start the interior decoration.