On Feb 20, 2006, at 5:19 PM, [EMAIL PROTECTED] wrote:
G'day all.
Quoting Robert Dockins <[EMAIL PROTECTED]>:
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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
