PROPOSAL: toBoundedIntegral: an adaptation of fromIntegral that respects bounds

[Edward Kmett]

"Sized" seems kind of strangely named to me.

On Mon, Nov 17, 2014 at 4:10 AM, Sean Leather <sean.leather at gmail.com>
wrote:

> On Mon, Nov 17, 2014 at 10:42 AM, Herbert Valerio Riedel wrote:
>
>> On 2014-11-16 at 11:51:11 +0100, Sean Leather wrote:
>> > 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?
>>
>> Fwiw, I'd be fine with all of `{to,from}{SizedIntegral,IntegralSized}`.
>>
>
> Excellent.
>
> I do think it's more useful to use a name that identifies the direction to
> or from the more restrictive type and/or constraints. For example,
> 'fromIntegral :: (Integral a, Num b) => a -> b' identifies that it's
> converting from a more restrictive constraint to a less restrictive.
> 'toBoundedIntegral' does the reverse; therefore, I think it's useful to use
> 'to' instead of 'from'. Whereas, for 'toSizedIntegral', the constraints are
> equivalent, but the size of the result type may be smaller. So, I think
> 'to' is better than 'from' in this case.
>
> (my only concern would about the (mathematical) term 'integral' which is
>> a bit overloaded (try searching for "bounded integral"), but given
>> Haskell already established a precedent by 'fromIntegral' I guess
>> there's little risk of confusion here)
>>
>
> I can see that "bounded integral" and "sized integral" are somewhat
> ambiguous if you are not trained in the 'fromIntegral' thinking. And
> putting something in the middle of 'to' and 'Integral' may make it less
> obvious that these functions are related to 'fromIntegral'.
>
> So is there any reason not to settle on 'toIntegralBounded' and
> 'toIntegralSized'?
>
> > 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.
>>
>> about the RULEs... do we really need them for `toBoundedIntegral`? If
>> you make `toBoundedIntegral` INLINEABLE, shouldn't you be able to
>> inherit the ones from 'fromIntegral' (which is what `intCastMaybe`
>> exploits)?
>>
>
> I didn't try that. I'll give it a shot.
>
> > Where should the functions go? intCastMaybe/toSizedIntegral could go in
>> > Data.Bits. What about toBoundedIntegral?
>>
>> There's also
>>
>>   http://hackage.haskell.org/package/base-4.7.0.1/docs/Numeric.html
>>
>> as a candidate
>>
>
> Works for me. We could rename the section “Miscellaneous” to “Conversion”
> and put both functions there. Also, we should probably revise the module
> description since there is already a lot more than “functions for reading
> and showing RealFloat-like kind of values.”
>
> 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/20141117/6d82c9b8/attachment.html>