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

[David Feuer]

Another approach is to ask "which is larger, and by how much?" to which the
answer is Either the Left or the Right.
On Nov 13, 2014 11:22 AM, "Daniel Díaz" <dhelta.diaz at gmail.com> wrote:

>  I am +1 on having Natural in base, I don't really mind the place
> (although I also admit that Data.Word seems odd to me).
>
> About subtraction. For the Num instance of Natural, I'd prefer (x - y)
> where (y > x) to fail with an error call. This is
> consistent with the behavior we already have for division. The type `(-)
> :: Natural -> Natural -> Natural` forces us to return
> a value for any pair of naturals. However, subtraction is not defined for
> every pair, so it makes sense to me for the function
> to be partial.
>
> That being said, I consider myself an enemy of partial functions (head,
> tail, and family), and I'd probably prefer to use subtraction
> with the following type:
>
> safeSubtract :: Natural -> Natural -> Maybe Natural
>
> With this type, we are not forced to return a value for every pair,
> returning Nothing instead for those cases where subtraction does not make
> sense. This is, IMHO, the best way to subtract naturals.
>
> Best regards,
> Daniel Díaz.
>
> On 11/13/2014 01:03 AM, Sean Leather 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 listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> 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/43044d31/attachment.html>