Re: A possible solution?

[scgmille@xxxxxxxxxxxxxxxxxx]

On Thu, Oct 30, 2003 at 07:12:35AM -0800, bear wrote:
> 
> 
> On Thu, 30 Oct 2003, Anton van Straaten wrote:
> 
> > This could make a nice reference implementation.  It's not completely clear
> > to me whether you're also suggesting that this should be something that the
> > spec requires of implementations, though.  I don't see the need for it in
> > implementations that already provide a generic dispatch mechanism - it would
> > only add overhead.
> 
> I'm advocating a public interface for collection-generic functions.
> The generic-dispatch mechanisms you're talking about aren't public.
> 
> If the objective is that I can "drop-in" a collection library developed
> anywhere, on any scheme system, and have it work with the local SRFI-44
> implementation, then we need a specific, published, data format for
> collection objects that allows the collection-generic functions to do
> efficient dispatch in an obvious way using R5RS semantics.
> 
> Right now, vectors (or possibly records) are the highest level of
> compatibility that can be targeted by library code.
> 
> So, yes, I'm advocating that the spec should require all collections
> that are going to work in this "generic collections framework" to
> adhere to a specific published data format -- probably as vectors
> or records encapsulating all the needed functions.

I feel that this will overly limit the usefulness in the long term.  In 
the short term, yes, it may allow for drop in collections, but should a 
real generic dispatch standard come about, it would not only invalidate 
the mechanism you're describing, but the rest of SRFI-44 as well since 
they would be specified in the same place.

It makes more sense to me to leave the implementation open, and possibly 
follow up more or less immediately with an interface for adding 
collections, with a reference implementation like the the system you 
describe.  That way we get the best of both worlds... the ability to 
drop in collections in the short term without the ticking time bomb of 
eventual invalidation.

	Scott

Attachment: pgp2fGJTR1DRW.pgp
Description: PGP signature