Data.Map, Data.IntMap documentation

[Adrian Hey]

Arie Peterson wrote:
> Adrian Hey wrote:
> 
>>> The Ord-constraint is too limiting for tries.
>> Well it isn't going to disappear while I'm in charge of GT class :-)
>> Why do you object to it? Ultimately we must be able to test keys
>> for equality at least. Is there a type that is an instance of Eq,
>> but not Ord (or could not reasonably be made an instance of Ord)?
> 
> Complex numbers, and trees, and probably many more. Some types do not have
> a natural total ordering. Sure, you can pick some arbitrary one, but that
> can be confusing, and it decreases the ability of the type system to catch
> semantic errors.

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.

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.

Regards
--
Adrian Hey