PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds

[Sean Leather]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141112/efc21bb3/attachment.html>