On Wed, Nov 12, 2014 at 3:04 PM, Herbert Valerio Riedel wrote:

On 2014-11-12 at 12:57:16 +0100, Sean Leather wrote:
>> 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'.

I see, that's true. As far as I'm concerned, toInteger works well for the ->Integer direction and toBoundedIntegral works well for the Integer-> direction. My primary use for toBoundedIntegral is for larger-to-smaller integral type conversions.

> 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.

I meant that I don't know how often having a Bounded instance and no Bits instance (or vice versa) happens in practice. In other words, I'm not sure which is more likely needed – a function with a Bounded constraint or a function with a Bits constraint – or if it really matters much at all.

> 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)

Works for me. I'd be happy with either one or both.

> 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)

Exactly.

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)?

Good bike-shedding question. In short, minimum ambiguity. To me, 'fromIntegralBounded' can be read as if the argument and not the result is Bounded. I felt 'toBoundedIntegral' used the convenient “adjective-ness” of 'Bounded' and 'Integral' to unambiguously describe the result.

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

Thanks. My fingers have a tendency to type 'case' instead of 'cast'. Too much pattern-matching and too little conversion? Who knows. ;)

Regards,
Sean