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

[David Feuer]

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/b297cfeb/attachment.html>