PROPOSAL: Add 'Natural' type to base:Data.Word
John Lato
jwlato at gmail.com
Thu Nov 13 06:28:18 UTC 2014
On Thu Nov 13 2014 at 2:04:31 PM Sean Leather <sean.leather at gmail.com>
wrote:
>
> 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.
>
Simple. If my code expects saturation, and the semantics change to a
partial function, I get an exception and can easily fix it. If my code
expects exceptions for invalid subtractions, and the exception path is
replaced with a saturating operation, I'll just get incorrect values, which
are much more difficult to track down.
I think it's important to get the semantics right from the beginning when
there's no cost to changing them, so it's worth spending some time
discussing the pros and cons here.
> 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.
>
That is an option, but it's one that seems rarely taken in Haskell. I
think most people would expect alternate semantics via newtypes.
It doesn't particularly matter to me how this is resolved, but I do find it
slightly odd that so many people seem to be arguing for a partial function
as the default in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/815d8056/attachment-0001.html>
More information about the Libraries
mailing list