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

Sean Leather sean.leather at gmail.com
Thu Nov 13 06:03:56 UTC 2014


Iavor laid out the options nicely, so I'm building off of his response.

On Wed, Nov 12, 2014 at 9:16 PM, Iavor Diatchki wrote:

> 1. I like the idea of having a `Natual` type similar to `Integer`, so +1
> from me.
>

A definite +1 from me, too.

2. I am a bit worried about the partiality of some of the operations, but I
> don't see an appealing alternative... I guess we should just throw some
> informative exceptions.
>

I agree, but see my response to John Lato below.

3. I don't mind where it lives, although `Data.Word` does seem a little odd.
>

Agreed with this, too, but I'm not sure of a better place. Would it be
worth exporting Integer from Data.Int to have symmetry? Or is that silly?

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.

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.

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/161bd2e0/attachment.html>


More information about the Libraries mailing list