Fundamental design constraints

[scgmille@xxxxxxxxxxxxxxxxxx]

Even if the SRFI were withdrawn, when I resubmit it for draft it would 
still contain the following major design attributes, which are 
essential to a successful collections interface.  

1. Generic dispatch:  This is absolutely essential in order to write
collection agnostic code.  Without this ability, you cannot write
generic logic that acts on collections.  This is the foundation of 
a large body of library code in languages with collections.

2. Necessary operators (as opposed to a Kitchen Sink):  This
follows the general Scheme philosophy.  There are two reasons for
including necessary operators rather than all possible operators.  
Firstly, choosing a necessary subset contstrains future collections 
less.  This is essential because one cannot hope to guess what
collections will be used in the future.  Odd collections are an even 
tougher match, such as infinite collections, generated collections,
and external-sourced collections.  Secondly, it keeps the barrier to
mapping data structures to the SRFI low and allows for efficient 
implementation of the necessary set, as well as allowing future 
operators in those collections to be efficient.  Having too many 
specific operators means those operators will have widely varying
efficieny on future collections... when they can be made to work at all.

3. Metaness - This is just too important in order to have a framework
for collections interoperability.  As in [1], the real power of a 
collections framework comes not from the specific collections that are
eventually created, but the fact that the collections can be used with 
each other, passing values and mappings between them, and being able to 
interchange collections and pass them to functions as easily as we do 
with higher order functions in Scheme.

4. Enumeration - A traversal mechanism is a must for collections.  
Iterators/Cursors have problems as noted previously on the list.  
Enumerations have been shown to have advantages where iterators have 
weaknesses, and yet the advantages of cursors are a conversion operator 
away.  Its the best of both worlds, and the Right Thing.

For this reason arguments for withdrawal citing any of the above are 
immaterial, and I will start ignoring any comments about them towards 
withdrawal.  Additionally, the SRFI process arguments are outside the 
scope of discussion.  We can continue to discuss this on the 
srfi-discuss list if you like, but its just wasting bandwidth at this 
point, given that even the editor doesn't agree that this SRFI is 
abusing the process in a harmful manner.

I'm extending an olive branch to continue rational discussion of 
improving the flaws that remain.  I've updated the SRFI at 
http://sgmiller.org/code/srfi-44.html to reinsert the references section 
and add *-get-all to the dictionary API to support m-to-n mappings.  
Lets stop bickering and fix the issues that remain.  

	Scott

Attachment: pgpbZAOjgWMsr.pgp
Description: PGP signature