Neil Mitchell wrote:
Other rules that could be interesting are:
> forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
> forall a b. fromInteger a * fromInteger b = fromInteger (a * b)
This is wrong, since the class function can do what it wants. Imagine:
instance Num String where
(+) = (++)
fromInteger x = show x
1 + 2 :: String
this expression now goes from "12" to "3" by applying this rule.
You need to be incredibly careful if there are any classes floating around.
Do we assume Num instances to obey Num axioms, just like Arrow instances
to obey Arrow axioms? My impression is that the GHC de-sugaring of the
proc notation contains an optimizing stage that uses arrow axioms. This
is a good precedence.
If Num obeys ring axioms, fromInteger is a perfectly fine
ring-homomorphism. (It's also the first or second homomorphism taught.)
If a and b are large integers and the target ring is small, fromInteger
(a + b) is likely slower. That is my concern.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
