robdockins at fastmail.fm
Mon Mar 6 10:11:26 EST 2006
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
> Will this make Jean-Philippe's work obsolete?
> 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
> "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!
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Libraries