PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds

[Edward Kmett]

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.

-Edward



On Wed, Nov 12, 2014 at 8:36 AM, Sean Leather <sean.leather at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141114/c9564cd2/attachment.html>