PROPOSAL: Add 'Natural' type to base:Data.Word

Carter Schonwald carter.schonwald at gmail.com
Thu Nov 13 06:15:21 UTC 2014


indeed.

I think the Saturating option should be the newtyped one, and the
"expected" one should be the default. Anything else is out of scope for the
original proposal on the table and easily a long running bikeshed blood
bath.

On Thu, Nov 13, 2014 at 1:03 AM, Sean Leather <sean.leather at gmail.com>
wrote:

> Iavor laid out the options nicely, so I'm building off of his response.
>
> On Wed, Nov 12, 2014 at 9:16 PM, Iavor Diatchki wrote:
>
>> 1. I like the idea of having a `Natual` type similar to `Integer`, so +1
>> from me.
>>
>
> A definite +1 from me, too.
>
> 2. I am a bit worried about the partiality of some of the operations, but
>> I don't see an appealing alternative... I guess we should just throw some
>> informative exceptions.
>>
>
> I agree, but see my response to John Lato below.
>
> 3. I don't mind where it lives, although `Data.Word` does seem a little
>> odd.
>>
>
> Agreed with this, too, but I'm not sure of a better place. Would it be
> worth exporting Integer from Data.Int to have symmetry? Or is that silly?
>
> On Thu, Nov 13, 2014 at 2:51 AM, John Lato wrote:
>
>> +0.9 for saturated subtraction.
>> Playing devil's advocate, the downside is that if a user forgets to check
>> the subtraction preconditions, saturated subtraction will silently give the
>> wrong answer instead of calling error.  So for a (relatively common?)
>> mistake, the consequences will be worse (exceptions are better than wrong
>> values).
>>
>> However, this is balanced by several use cases for which saturated
>> subtraction is the desired behavior.  Furthermore there's no existing code
>> to break, so now is the time to make this choice (it would be easier to go
>> to a partial function in the future than vice versa).
>>
>
> I'm not sure how it would be “easier to go to a partial function” if your
> code expects saturation.
>
> Here's another option: Provide total (or partial) functions by default in
> the Num and other instances, and provide supplementary partial (total)
> functions for those who want the other semantics.
>
> 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/20141113/9fbe5827/attachment.html>


More information about the Libraries mailing list