Data.Map, Data.IntMap documentation

[Arie Peterson]

Adrian Hey wrote:

> True, but in practice it's hard to think of any Ordering that isn't
> completely arbitrary, other than reals perhaps. It isn't obvious to
> me that 'A' is less than 'B', or (1,2) is less than (2,1).
> But I don't see this as a big problem.

Well, we could debate the naturality of these orderings, but that is
beside my point, because these instances are in the standard libraries.

Some data types (both in libraries and "user defined") *deliberately* do
not have Ord instances, and currently Data.Map does not play nice with
this choice.

For example, when I write 'someTree < otherTree' the compiler shouts at me
and helps me realise that I actually meant 'height someTree < height
otherTree'. This mechanism fails once I need trees to be keys in a map. My
current solution (newtypes) is far from ideal.

> It seems to me that there's no getting away from arbitraryness.
> Say the GT class abandoned the Ord constraint and just provided..
>
>   assocs :: map a -> [(k,a)]
>
> which returned the list of associations in some *arbitrary* (unspecified
> but still deterministic) order of keys. Is that any better? I would
> prefer to have some universal default ordering for any key type that
> was used consistently by various APIs, even if the ordering is
> arbitrary.

I'm all for arbitrary orderings, as long as they don't "pollute" the Ord
class :-).


Greetings,

Arie