I like this idea. Why not put *both* options in newtype-wrapped interfaces over an underlying version with unchecked subtraction?

On Nov 12, 2014 8:24 PM, "Carter Schonwald" <carter.schonwald@gmail.com> wrote:

Hrmm.  Whichever semantics is chosen as the default, I hope the alternative semantics IS available via a newtype wrapper interface :) 

On Wed, Nov 12, 2014 at 7:51 PM, John Lato <jwlato@gmail.com> 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).

John L.

On Thu Nov 13 2014 at 2:17:52 AM Gershom B <gershomb@gmail.com> wrote:

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

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries