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

[David Feuer]

Yes,  you're right of course.
On Nov 13, 2014 12:06 PM, "Andreas Abel" <andreas.abel at ifi.lmu.de> wrote:

> On 13.11.2014 17:24, David Feuer wrote:
>
>> Another approach is to ask "which is larger, and by how much?" to which
>> the answer is Either the Left or the Right.
>>
>
> Yes, but one would have to have three outcomes:  the Left is larger by n,
> the Right is larger by n, or they are Equal.  Otherwise the result for
> equal nats is a bit arbitrary.  (See Conor McBride's Compare type family.)
>
>   compare m n = LT k  ==>  m+k+1 = n
>   compare m n = EQ    ==>  m = n
>   compare m n = GT k  ==>  m = n+k+1
>
>>
>> On Nov 13, 2014 11:22 AM, "Daniel Díaz" <dhelta.diaz at gmail.com
>> <mailto: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 list
>>>     Libraries at haskell.org  <mailto:Libraries at haskell.org>
>>>     http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/28559b06/attachment.html>