On Mar 6, 2006, at 8:27 AM, Christian Maeder wrote:
Robert Dockins wrote:
The second release candidate for Edison 1.2 is now ready for comments.
Will this make Jean-Philippe's work obsolete?
http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework
Being (currently) no enthusiast anyway, I would not even know which classes to choose now, since Edison has been improved.
I personally have no particular stance on this. Jean-Philippe's design is quite different from Edison's and in the absence of focus groups and user studies we don't have any real information about what design appeals best to programmers. I suspect that, in the end, only one type-class data structure abstraction will gain widespread use, but I'm not going to make any predictions at this point. Obviously, standardization decisions can have a strong impact on this process. As for myself, I'll probably be using Edison, because I'm pretty familiar with it ;-)
-- What do you think about the symbolic operators?
I prefer alphanumeric identifiers.
So do I, as it happens :-) Which is why the symbols are only aliases.
In addition, I'm interested in any API related feedback you might have.
Data.Edison.Assoc.fold
"Combine all the elements in the associative collection, given a combining function and an initial value. The elements are processed in an unspecified order. Note that fold ignores the keys."
This fold function looks pretty unsafe to me, because (the common) "fold (:) []" might reveal implementation details that one wants to hide. Such a function should be called "structuralFold" (or something like that).
I'm not sure I understand; why do you think that revealing structure is unsafe? It's not like you can subvert the program with this additional knowledge. Obviously, if you rely on the elements being provided in some particular implementation-dependent order than your code is broken (perhaps this should be more explicit in the docs?). I'm hesitant to give "fold" a longer name because I think it should be the first fold a programmer reaches for. In the fairly common case where you have a commutative, associative function (eg (+)), you don't care in what order the function is applied to the elements, and you have fold f z === foldl f z === foldr f z. Why should you prefer "fold"? Because it gives data structure implementers the freedom to define a fold that is more efficient than foldr or foldl or whatever else (usually, as you surmised, by following the internal structure). In light of this and previous discussions about folds, I think I will be adding a section to the docs about how to chose an appropriate fold for your application.
Cheers Christian
Thanks for your comments! Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG