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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
