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

Re: Reasons for withdrawal



On Wed, Oct 29, 2003 at 12:02:06PM +0900, Alex Shinn wrote:
> 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.

Not at all. The SRFI merely requires typed base dispatch, which can be 
as simple as a cond statement with several tests for the concrete 
collection types.  There is simply no way to have genericly programmable 
collections without some generic dispatch mechanism.  Nearly all Scheme 
implementations currently have it.  

Note also that this is not a fatal issue.  Many SRFIs are not portably 
implementable (even though this one is!) but the SRFI process definitely 
allows for that.

>   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.

I half agree.  But this SRFI is careful to choose operators that do 
apply to all members future collections.  Approaching the problem from 
the other direction means that unification has to happen as a 
retrospective act, which is likely to be awkward or impossible.  Also 
note that its not made illegal for very odd collections to deviate from 
the SRFI, it just means they will not necessarily interoperate well with 
other collections.  You'd have the very same problem working from the 
other direction, where the collections won't play well at all given 
absolutely no framework for interoperability.  And for very odd 
collections, perhaps they don't need to interact.

	Scott

Attachment: pgpInZHcZGb6L.pgp
Description: PGP signature