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

Carter Schonwald carter.schonwald at gmail.com
Thu Nov 13 01:23:47 UTC 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141112/e16cd894/attachment.html>


More information about the Libraries mailing list