This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
On Mon, Oct 20, 2003 at 03:36:20PM -0500, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> I've updated http://sgmiller.org/code/srfi-44.html. The general
> method is *-get. Sequences and ordered collections have a *-get-left,
> *-get-right as well.
Comments on the latest draft:
1. Mutable collections
Is this the best name for the property? Just a quibble, but users may
misunderstand the meaning of (not (mutable? c)) as "can't change the
values" rather than "can't use the !! procedures."
2. Reversible collections
This mixes up the two reversibility-related features.
reversible -> backwards enumeration is POSSIBLE
bidirectional -> backwards enumeration is EFFICIENT
Of the two, "reversible" is more important, because it affects the
interface. The text as written uses the "reversible" name, but it
actually describes a "bidirectional" collection.
Recommendation: Fix the definition so that it actually describes
reversibility. Optionally, also include the "bidirectional" trait.
3. Folding enumerators
The enumerators do not match the interface or semantics for *-get.
Specifically, it requires that collection-fold is a left-fold instead of
an arbitrary fold.
Recommendation: Match the new interface for *-get. Provide:
collection-fold arbitrary/convenient/efficient order
*-fold-left in-order enumeration
*-fold-right reverse-order enumeration
Issue: Should it be collection-fold-left or *-fold-left? In other words,
are the directional enumerators defined for all collections or only for
directional collections? If the former, then what do they do to an
unordered bag?
4. Immutable Collections
Shouldn't there be a predicate for this?
5. Size versus Length
I'd like a suggestion that collection-size should return the number of
iterations of collection-fold, if possible. No big deal if you disagree.
6. Infinite collections
I agree with the sentiment of the second paragraph -- cycles don't
necessarily imply an infinite sequence -- but I think the text
overconstrains implementations too much. It suggests to me that a finite
data structure can never produce an infinite sequence, which I disagree
with. It'd be better to say, "Don't make it infinite just because you're
lazy; only do it when that's what you really mean." I'm not sure how to
express that more clearly without being insulting, though.
7. Ordered Collections ... Value Equality
Recommendation: Somewhere in here, point out that you can usually adapt
a strict-weak ordering function for use as an equivalence function.
Recommendation: Explicitly state that dictionaries should use the
ordering function or the value-equivalence function as a default if you
don't provide a separate one. Or at least insist that each collection
document the default.
8. Sequences
Shouldn't there be a predicate to test for fixed-size sequences, since
it affects the defined interfaces? Also, sequences should not be
subtypes of bags unless bags also have a fixed-size interface.
9. Procedures
There are a lot of *-left and *-right operations defined for
non-directional containers. For example, the bag still has *-insert-left
and *-insert-right, which don't make any more sense than *-get-left
does. Also, I didn't do a good job earlier of specifying exactly when
*-left and *-right make sense.
If a container has *-method, then it should have
*-method-left if sequence?, ordered?, or reversible?
*-method-right if reversible?
For example, a bag should only have *-method-left if it's ordered or
reversible, and *-method-right only if it's reversible.
Also, "insert-left" and "insert-right" should probably be "add-left" and
"add-right." That way, INSERT and DELETE always require an index or key,
REMOVE always requires a value, and ADD never requires any of them.
Likewise, dictionaries should probably use INSERT and DELETE instead of
PUT and REMOVE. Dictionaries are a lot like sequences with arbitrary
indices, yet the interface isn't much like the sequence interface at
all.
In short, I think the procedures section needs an editorial overhaul to
correctly incorporate the changes, and it needs some interface changes
to reduce unnecessary incompatibilities between different collection
types.
I'll happily help with that overhaul if you like; after all, I am trying
to help, not trying to be a trouble-maker!
--
Bradd W. Szonye
http://www.szonye.com/bradd