Sun, 11 Feb 2001 13:37:28 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would
happen to Ord and the numeric classes with default class method
definitions that use (==) either explicitly or in pattern matching
against numeric literals?
Sun, 11 Feb 2001 13:37:28 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would
happen to Ord and the numeric classes with default class method
definitions that use (==) either explicitly or in pattern matching
against numeric literals?
I
Marcin 'Qrczak' Kowalczyk wrote:
I'm against removing Eq from the numeric hierarchy, against making Num
instances for functions, but I would probably remove Show. I haven't
seen a sensible proposal of a replacement of the whole hierarchy.
Then we probably are in agreement.
--brian
On 11-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
There may be some misunderstanding here. If you are talking about type
for which equality is always undefined, then I agree with you, but that
is not what I was talking about. I was thinking about types where
equality is defined for some
Marcin 'Qrczak' Kowalczyk wrote:
Sat, 10 Feb 2001 14:09:59 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would happen to
Ord, and the numeric classes that require Eq because they need signum?
signum doesn't require Eq. You can
Fergus Henderson wrote:
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the
On 11-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Fergus Henderson wrote:
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only
Brian Boutel [EMAIL PROTECTED] writes:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the problem.
There is nothing trivial or ugly about a definition that reflects
Ketil Malde wrote:
Brian Boutel [EMAIL PROTECTED] writes:
- Having a class hierarchy at all (or making any design decision)
implies compromise.
I think the argument is that we should move Eq and Show *out* of the
Num hierarchy. Less hierarchy - less compromise.
Can you demonstrate
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the problem.
...
There is nothing
Sat, 10 Feb 2001 14:09:59 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would happen to
Ord, and the numeric classes that require Eq because they need signum?
signum doesn't require Eq. You can use signum without having Eq, and
you can
"Ch. A. Herrmann" answers my questions:
Jerzy What do you mean "predefined" operators? Predefined where?
In hugs, ":t (*)" tells you:
(*) :: Num a = a - a - a
which is an intended property of Haskell, I suppose.
Aha. But I would never call this a DEFINITION of this operator.
This
12 matches
Mail list logo
