PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds

[Herbert Valerio Riedel]

On 2014-11-12 at 12:57:16 +0100, Sean Leather wrote:

[...]

> I'd love to be able to depend on the fromIntegral RULEs instead of adding
> toBoundedIntegral RULEs, but I found cases where the fromIntegral RULEs
> were not firing. So I thought I would make GHC's job easier by including
> all of the RULEs. If there's a better way, I'm all for it.

I didn't realise fromIntegral suffered from the same issue. I'm afraid I
don't know a better way with the current infrastructure either :-/

>> Moreover, you limit yourself to 'Bounded' types (which is why I resorted
>> `Bits` rather than 'Bounded' for 'intCastMaybe' after noticing that I
>> couldn't convert from (half)unbounded 'Integer' or 'Natural' to/from
>> bounded types).

> I'm not sure how the function is “limited” by using Bounded. 

I meant limited in that it excludes converting to/from integral types
such as 'Integer'.

> Aren't they just different constraints? If your type doesn't have a
> Bits instance but does have a Bounded, then you would use the function
> that required Bounded.  How often this happens in practice, I don't
> know.

IMHO, It happens quite a lot actually that you go via 'Integer' to make
sure you don't silently incur arithemtic overflows. I personally tend to
do that in code where I'm interested in using checked conversions like
`toBoundedIntegral` in the first place.

> Anyway, I don't see a reason why we couldn't have both toBoundedIntegral
> and intCastMaybe. Or, if you prefer intCastMaybe, let's use that instead.
> I'm not strongly tied to toBoundedIntegral, but it would be nice to see
> something in base because more people will see it.

I guess that if we add toBoundedIntegral, I'd like to see toBitsIntegral
as well. (IOW, I'd be +0.5 for adding both functions up to
bikeshed-isomorphism)

>> So I'm on the fence about 'toBoundedIntegral', as for one I want such a
>> facility for conversion, but OTOH, I'm not happy with the limitations
>> 'toBoundedIntegral' exhibits. I'd like to see a more general solution.
>
> Just to be clear, I understand one limitation you've presented: the RULEs.
> You mentioned limiting to Bounded, but I'm not clear how that's a
> limitation compared to using Bits, as you do.
>
> What do you mean by a more general solution? IMHO, this is simply a
> “better” fromIntegral, and fromIntegral is used a lot for bounded types. I
> don't see how having toBoundedIntegral or intCastMaybe precludes or
> diminishes other developments, esp. ones that deal with more type
> information. These functions are useful as they are now for many types.

As stated above, if it's on the table to add both, I'm +0.5. As you say,
they are indeed useful given the current infrastructure (which only
gives us Integral/Enum/Num/Bounded/Bits to work with at this point)

I'm curious though, if it's supposed to be a better 'fromIntegral', why
did you chose the name 'toBoundedIntegral' rather than
'fromIntegralBounded' which has more resemblance to 'fromIntegral' (and
has a closer tab-complete-distance to it as well)?


Cheers,
  hvr

PS: I've s/intCaseMaybe/intCastMaybe/ in the quoted parts to avoid confusion