On Wed, Oct 29, 2003 at 12:02:06PM +0900, Alex Shinn wrote:
> At Tue, 28 Oct 2003 14:35:15 -0600, xxxxxx@freenetproject.org 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