[Haskell] Long live Edison

[Robert Dockins]

On Feb 20, 2006, at 5:19 PM, ajb at spamcop.net wrote:

> G'day all.
>
> Quoting Robert Dockins <robdockins at fastmail.fm>:
>
>> Although I am not a data structures expert, several weeks ago I
>> decided that I would try my hand at maintaining Edison and see if I
>> could overcome these barriers.  Toward this end I have taken the most
>> recent Edison codebase I could find (from Andrew Bromage's HFL
>> project) and updated it in the following ways:
>
> Yay!  Thanks for doing this.  Maybe I can close down HFL now. :-)
>
>> -- The Sequence 'rcons' method takes its arguments in the opposite
>> order as the 'lcons' method (for mnemonic purposes).  Should the
>> arguments to 'rcons' be reversed?
>
> The argument is that they both take their arguments in the order
> that they would do were they implemented with concatenation:
>
>     lcons x xs === [x] ++ xs
>     rcons xs x === xs ++ [x]
>
> This certainly makes sense to me.  Is there an argument for using
> the other order?

Consistency.  Almost all the other API functions take the data  
structure argument last.  This seems to be a kind of de facto  
standard and deviations from it are likely to cause confusion.

In Edison 1.1, the collection and associative collection APIs had  
several functions with the "opposite" order, but I reversed those to  
match usage of Data.{Set,Map}.  Now Sequence is the only class which  
still contains methods with the data structure in other-than-last  
position; 'rcons' is one of these, 'inBounds' another, and the  
'lookup*' functions are the others.  This makes for a total of about  
6, in an API consisting of about 200 functions.


>> -- There are a few places where 'Data.Map' and/or 'Data.Set' have
>> methods named similarly (but not identical) to the Edison API.  By
>> and large I have left those differences.  Should I instead modify
>> Edison to match those names?
>
> If you want to change it, change it to whatever makes the most sense
> for you.  (This, for example, is why I dumped all of the old Edison
> Maybe-like data structures in favour of a NotJustMaybe-like interface.
> It made more sense at the time.)
>
> Data.Set, Data.Map, Data.Hash and the various Array interfaces are all
> inconsistent in subtle ways, so whatever you do, do not take them as
> the ideal to which Edison should aspire.

This is all true.  The main advantage that the current Data.* APIs  
have is that people use them ;-)

> A better idea would be to
> look at all of them, and decide which convention you think makes the
> most sense.  An even better idea is to lay out the differences and
> invite feedback on which is best.

That is a good idea.  I will think on this.


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG