19 Mar 2013 23:58

## 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.
```
20 Mar 2013 00:05

### Re: Associated types for number coercion

On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done wrote:

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

```_______________________________________________
```
20 Mar 2013 00:22

### Re: Associated types for number coercion

```On 20 March 2013 00:05, Johan Tibell <johan.tibell <at> gmail.com> 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.
```
20 Mar 2013 00:24

### Re: Associated types for number coercion

```(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 <chrisdone <at> gmail.com> wrote:
> On 20 March 2013 00:05, Johan Tibell <johan.tibell <at> gmail.com> 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.

_______________________________________________
```
20 Mar 2013 00:54

### Re: Associated types for number coercion

```On 20 March 2013 06:58, Christopher Done <chrisdone <at> gmail.com> wrote:
> 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).