s***@public.gmane.org
2003-10-29 14:17:42 UTC
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
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