PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds

Sean Leather sean.leather at gmail.com
Sun Nov 16 10:51:11 UTC 2014


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

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


On Fri, Nov 14, 2014 at 7:17 PM, Edward Kmett wrote:

> I'm personally weakly +1 on this.
>
> I've needed and duplicated the functionality before, and its just tricky
> enough to cross the Fairbairn threshold, and baroque enough to be centrally
> maintained with all the rewrite RULES to make it fast.
>
> I don't have a strong preference over just doing this / doing both this
> and fromBitsIntegral.
>

Okay. Assuming the lack of response implies lack of interest, there doesn't
seem to be a lot of interest. But of those who responded, there is weak
positive interest. So I'm going to push a bit more to gauge interest and to
see what to do next.

We have now two options on the table:

   1. toBoundedIntegral :: (Integral a, Integral b, Bounded b) => a ->
   Maybe b
   2. intCastMaybe :: (Integral a, Integral b, Bits a, Bits b) => a ->
   Maybe b

As a user of these functions, I read the first type as a conversion from a
possibly unbounded integral type to a bounded integral type, while the
second type isn't as explicit (to me) about its implementation or intended
purpose. But it is clear that the second offers conversions between
unbounded types, while the first does not. (This is important considering
the new addition of Natural.)

We also have the Natural type being discussed in a separate thread. My
impression of that thread is that people are enthusiastic about the
inclusion, if only concerned about how to deal with partial operations.

With that in mind, I think this is an appropriate time to extend the base
library to add support for converting between integral types while
respecting bounds and sizes.

Therefore, I unambiguously propose adding both functions. I think they are
both useful in their own ways (which are obviously overlapping but can be
separate).

I do, however, suggest renaming intCastMaybe. Edward mentioned
fromBitsIntegral. I would suggest toSizedIntegral (or
fromSizedIntegral/fromIntegralSized, but I think toSizedIntegral is
meaningful since it describes the result, not the argument), since that
indicates the real usage of Bits in the function (which use bitSizeMaybe).
Other bikeshed colors?

Also, assuming there is enough interest (how much is enough?), I'd like to
know what the next steps should be.

Should someone create a Phab diff for it? (I can try it; however, I haven't
yet used Phab, so, Herbert, if you want to do it with your code and mine,
you can.) Also, we have to consider the Natural proposal and the
toBoundedIntegral RULEs for it.

Where should the functions go? intCastMaybe/toSizedIntegral could go in
Data.Bits. What about toBoundedIntegral?

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141116/05c60641/attachment.html>


More information about the Libraries mailing list