On Thu Nov 13 2014 at 2:04:31 PM Sean Leather
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.
Simple. If my code expects saturation, and the semantics change to a partial function, I get an exception and can easily fix it. If my code expects exceptions for invalid subtractions, and the exception path is replaced with a saturating operation, I'll just get incorrect values, which are much more difficult to track down. I think it's important to get the semantics right from the beginning when there's no cost to changing them, so it's worth spending some time discussing the pros and cons here.
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.
That is an option, but it's one that seems rarely taken in Haskell. I think most people would expect alternate semantics via newtypes. It doesn't particularly matter to me how this is resolved, but I do find it slightly odd that so many people seem to be arguing for a partial function as the default in this case.