+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).
John L.
On Thu Nov 13 2014 at 2:17:52 AM Gershom B
Let me throw in one key bikeshed to be painted.
I don't like the fact that subtraction on naturals is a partial operation as proposed. I would much prefer saturated subtraction where for y > x, x - y = 0. This prior discussion on -cafe tends towards such a definition as being 'universally better'
https://www.haskell.org/pipermail/haskell-cafe/2011-March/090265.html
Here is my motivation for saturated subtraction: On all non-bottom calculations, it agrees. On calculations that are bottom under partial subtraction, it nonetheless gives a mathematically meaningful and useful result in a coherent way.
As a general principle, I think our goal should be to make base more total, not less.
The arguments cited in the thread from Runciman's "What About the Natural Numbers" (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3442) are also fairly compelling in this regard.
-g
Herbert Valerio Riedel wrote:
I hereby suggest to add a type for encoding term-level naturals... to `base:Data.Word` module
+1
because Edward, who is the current leading purveyor of term-level nats, is in favor.
Roman Cheplyaka wrote:
Yeah, having Natural in Data.Word feels unnatural to me.
Agreed. I'm not sure what the solution is though. I'd be in favor if someone comes up with something decent. *However* I'd be strongly opposed to letting any kind of bikeshedding getting in the way of Herbert's proposal.
Thanks, Yitz
Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries