Associated types for number coercion

From the paper Fun with Type Funs, it's said:
One compelling use of such type functions is to make type coercions implicit, especially in arithmetic. Suppose we want to be able to write add a b to add two numeric values a and b even if one is an Integer and the other is a Double (without writing fromIntegral explicitly).
And then an Add class is defined which can dispatch at the type-level to appropriate functions which resolve two types into one, with a catch-all case for Num. Has anyone put this into a package, for all common arithmetic operations? I would use it. Doing arithmetic stuff in Haskell always feels labored because of having constantly convert between number types.

On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done
From the paper Fun with Type Funs, it's said:
One compelling use of such type functions is to make type coercions implicit, especially in arithmetic. Suppose we want to be able to write add a b to add two numeric values a and b even if one is an Integer and the other is a Double (without writing fromIntegral explicitly).
And then an Add class is defined which can dispatch at the type-level to appropriate functions which resolve two types into one, with a catch-all case for Num.
Has anyone put this into a package, for all common arithmetic operations? I would use it. Doing arithmetic stuff in Haskell always feels labored because of having constantly convert between number types.
I prefer the current way (which is interestingly what Go chose as well). With implicit casts it's easy to shoot yourself in the foot e.g. when doing bit-twiddling. These two are different f :: Word8 -> Int -> Word32 f w8 n = fromIntegral (w8 `shiftL` n) f' :: Word8 -> Int -> Word32 f' w8 n = (fromIntegral w8) `shiftL` n

On 20 March 2013 00:05, Johan Tibell
I prefer the current way (which is interestingly what Go chose as well). With implicit casts it's easy to shoot yourself in the foot e.g. when doing bit-twiddling.
I don't think it's an either-or case, though, is it? I would use the magic implicitness when I don't care, like all the times I have to write fromIntegral because I have an Int here and an Integer there, and now I want to use them in a Double calculation, so my code ends up littered with "fromIntegral", or "fi". Elsewhere in the world, programmers just write arithmetic. When I would care, like in bit-twiddling, I would use the explicit conversions.

(But I get annoyed about having to convert between five string types
(String, Text, lazy Text, ByteString, lazy ByteString), so maybe I'm
just generally more bothered by the whole “not being able to just
write the program” than others.)
On 20 March 2013 00:22, Christopher Done
On 20 March 2013 00:05, Johan Tibell
wrote: I prefer the current way (which is interestingly what Go chose as well). With implicit casts it's easy to shoot yourself in the foot e.g. when doing bit-twiddling.
I don't think it's an either-or case, though, is it? I would use the magic implicitness when I don't care, like all the times I have to write fromIntegral because I have an Int here and an Integer there, and now I want to use them in a Double calculation, so my code ends up littered with "fromIntegral", or "fi". Elsewhere in the world, programmers just write arithmetic. When I would care, like in bit-twiddling, I would use the explicit conversions.

On 20 March 2013 06:58, Christopher Done
From the paper Fun with Type Funs, it's said:
One compelling use of such type functions is to make type coercions implicit, especially in arithmetic. Suppose we want to be able to write add a b to add two numeric values a and b even if one is an Integer and the other is a Double (without writing fromIntegral explicitly).
And then an Add class is defined which can dispatch at the type-level to appropriate functions which resolve two types into one, with a catch-all case for Num.
Has anyone put this into a package, for all common arithmetic operations? I would use it. Doing arithmetic stuff in Haskell always feels labored because of having constantly convert between number types.
hmatrix takes this approach with a Mul typeclass for combinations of Vector and Matrix multiplication, defined for things that can implement Product (real and Complex Doubles and Floats). http://hackage.haskell.org/packages/archive/hmatrix/0.14.1.0/doc/html/Numeri... I think it'd be interesting for numeric stuff to have implicit conversion to Double, using a class as you suggest which doesn't support Integral or bitops. Conrad.
participants (3)
-
Christopher Done
-
Conrad Parker
-
Johan Tibell