Edison 1.2rc2

[Robert Dockins]

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