Proposal: Add Peano numbers to base

[wren romano]

On Mon, Jan 11, 2016 at 12:29 PM, M Farkas-Dyck <m.farkasdyck at gmail.com> wrote:
> I have seen these redefined many times now. Examples:
> https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.html#t:Nat
> https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.html#t:T
> https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.html#t:N
> https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.html#t:Nat
> https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano
>
> I often see them used as DataKinds. Too, operations on them can be
> lazy, which is sometimes useful.
>
> I filed a ticket: https://ghc.haskell.org/trac/ghc/ticket/11402

I'm a fan of blessing some particular implementation in order to
minimize the code redundancy. Though I'd prolly suggest making it a
Platform package rather than rolling it into base itself (unless
there's some reason why it needs to be in base itself).

Wherever it ends up, I really like that the patch names the type Peano
rather than Nat. I often use Nat as a newtype of Int (and Natural as a
newtype of Integer) for when I need efficient implementations of
natural numbers, so it's nice to give the lazy unary representation a
different name.

-- 
Live well,
~wren