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

[Carter Schonwald]

...... what would the semantics of unchecked subtraction be?

On Wed, Nov 12, 2014 at 8:27 PM, David Feuer <david.feuer at gmail.com> wrote:

> 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 at 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 at 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 at 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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141112/a1039a49/attachment-0001.html>