Yes, you're right of course.
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@gmail.com
<mailto:dhelta.diaz@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@haskell.org <mailto:Libraries@haskell.org>
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org <mailto:Libraries@haskell.org>
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@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@gu.se
http://www2.tcs.ifi.lmu.de/~abel/