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

[Andreas Abel]

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/