Hans Aberg haberg at math.su.se
Wed Apr 9 12:04:30 EDT 2008

```On 9 Apr 2008, at 17:49, Henning Thielemann wrote:
> Additionally I see the problem, that we put more interpretation
> into standard symbols by convention. Programming is not only about
> the most general formulation of an algorithm but also about error
> detection. E.g. you cannot compare complex numbers in a natural
> way, that is
>   x < (y :: Complex Rational)
>  is probably a programming error. However, some people might be
> happy if (<) is defined by lexicgraphic ordering. This way complex
> numbers can be used as keys in a Data.Map. But then accidental uses
> of (<) could no longer be detected. (Thus I voted for a different
> class for keys to be used in Data.Map, Data.Set et.al.)

I think there it might be convenient with a total order defined on
all types, for that data-map sorting purpose you indicate. But it
would then be different from the semantic order that some types have.
So the former should have a different name.

Also, one might have
Ordering(LT, EQ, GT, Unrelated)
so t can be used on all relations.

>  Also (2*5 == 7) would surprise people, if (*) is the symbol for a
> general group operation, and we want to use it for the additive
> group of integers.

This is in fact as it should be; the idea is to admit such things:
class Group(a; unit, inverse, mult) ...

class (Group(a; 0, (-), (+)), Monoid(a; 1, (*)) => Ring(a; 0, 1,
(-), (+), (*)) ...
-- (or better variable names).

instance Ring(a; 0, 1, (-), (+), (*)) => Integer

A group can be written additively or multiplicatively, (+) is often
reserved for commutative operations. But there is not way to express
that, unless one can write
class AbelianGroup(a; unit, inverse, mult) where
...
satisfying
mult a b = mult b a
One would need pattern matching to Haskell in order to make this useful.

Hans

```