Proposal: Add Peano numbers to base

I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.... https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.... https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.h... https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.ht... 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 Discussion period: 2 weeks

On Mon, 11 Jan 2016, M Farkas-Dyck wrote:
I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.... https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.... https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.h... https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.ht... https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano
Type-level Peano number are also contained in: https://hackage.haskell.org/package/tfp-1.0.0.2/docs/Type-Data-Num-Unary.htm... and data-level Peano numbers in this playground module: http://code.haskell.org/~thielema/htam/src/Number/PeanoNumber.hs I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform. You might add a comparison of the packages to the Wiki page: https://wiki.haskell.org/Peano_numbers

Henning Thielemann
writes:
I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform.
+1 -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

Henning Thielemann
writes: I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform. +1 I don't necessarily want base to shrink as such, but I certainly think
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/01/16 18:59, John Wiegley wrote: the *scope* of base could stand to shrink. Furthermore, I don't see much value in adding this to base. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWlLn3AAoJENQqWdRUGk8BxPwQANRcPTJik63XBaTQvg6Pn59v litf0OksO+ACtT9Sdw2LdU0AJYXpdcg8MdMp5YDW3S0UTTeyr3EFgoioFirU0XVb icupB1RGvwkn+oD3d+vmdPncIi8/HzHbaxCph1OiOoB2//IGPVlo3q++GS9VXBkU 79ii3FsU4ofzRkMaalicKobOHV06JX3z0LahC1qc9jU9lLq14WaCIJg1wA/aCVBa S7PgcJE+itirCPDIOpJ7LlPSIpwFzix5eJvXZmYUL+sSxO/wpYJ2bXTUD3xZUq3d +q3cfg5+TMjm7yiPQmlkdLBjARZsLBpFMrxhZnrW2xUdAvvZZIaBFGIvE8TPWWHD mGIYNee/SPK4W7p5B4MA3ie+y/+glma/RXEZms3uDCThPI0DTsIZHo6s6tT3W7sB /ceHrgzMfsqflc8zIM1uyMY4Poy+N8wiwN8qnCkhF0s0TpORoBz9l+QBx+t72Lgm 3Gy6P9In4QeUrTrnYnJk/7bgwgY6s8fjBJ/OhURvavoyX8C60zNej9ChyYBybmQA QdIbNVfjEYRk6ED4r62fhCaacNsn9EJIfVzxiGqvNPsOIJWZ2QX/vrXo+azLjnoB ClqtDYQMdSiNAClsA0EKhxnf5/+3n6vsAwlzPegf6tczpOCSTHDUEW6W58AH9Sn4 c4fuhx3Q24wWkySIFnGZ =xwFn -----END PGP SIGNATURE-----

+1 to blessed, +0 to it being in base (agreed re: shrinking base) Tom
El 12 ene 2016, a las 03:31, Alexander Berntsen
escribió: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
> Henning Thielemann
> writes: I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform. +1 I don't necessarily want base to shrink as such, but I certainly think
On 11/01/16 18:59, John Wiegley wrote: the *scope* of base could stand to shrink. Furthermore, I don't see much value in adding this to base. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCgAGBQJWlLn3AAoJENQqWdRUGk8BxPwQANRcPTJik63XBaTQvg6Pn59v litf0OksO+ACtT9Sdw2LdU0AJYXpdcg8MdMp5YDW3S0UTTeyr3EFgoioFirU0XVb icupB1RGvwkn+oD3d+vmdPncIi8/HzHbaxCph1OiOoB2//IGPVlo3q++GS9VXBkU 79ii3FsU4ofzRkMaalicKobOHV06JX3z0LahC1qc9jU9lLq14WaCIJg1wA/aCVBa S7PgcJE+itirCPDIOpJ7LlPSIpwFzix5eJvXZmYUL+sSxO/wpYJ2bXTUD3xZUq3d +q3cfg5+TMjm7yiPQmlkdLBjARZsLBpFMrxhZnrW2xUdAvvZZIaBFGIvE8TPWWHD mGIYNee/SPK4W7p5B4MA3ie+y/+glma/RXEZms3uDCThPI0DTsIZHo6s6tT3W7sB /ceHrgzMfsqflc8zIM1uyMY4Poy+N8wiwN8qnCkhF0s0TpORoBz9l+QBx+t72Lgm 3Gy6P9In4QeUrTrnYnJk/7bgwgY6s8fjBJ/OhURvavoyX8C60zNej9ChyYBybmQA QdIbNVfjEYRk6ED4r62fhCaacNsn9EJIfVzxiGqvNPsOIJWZ2QX/vrXo+azLjnoB ClqtDYQMdSiNAClsA0EKhxnf5/+3n6vsAwlzPegf6tczpOCSTHDUEW6W58AH9Sn4 c4fuhx3Q24wWkySIFnGZ =xwFn -----END PGP SIGNATURE----- _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 11 January 2016 at 18:45, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Mon, 11 Jan 2016, M Farkas-Dyck wrote:
I have seen these redefined many times now. Examples:
https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano....
https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano....
https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.h...
https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.ht...
https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano
Type-level Peano number are also contained in:
https://hackage.haskell.org/package/tfp-1.0.0.2/docs/Type-Data-Num-Unary.htm...
and data-level Peano numbers in this playground module: http://code.haskell.org/~thielema/htam/src/Number/PeanoNumber.hs
I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform.
Same here, -1 on adding a particular implementation into base.
You might add a comparison of the packages to the Wiki page: https://wiki.haskell.org/Peano_numbers
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

This seems a clear consensus, so henceforth i consider this proposal dead.

On Mon, Jan 11, 2016 at 12:29 PM, M Farkas-Dyck
I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.... https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.... https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.h... https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.ht... 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
participants (7)
-
Alexander Berntsen
-
Alois Cochard
-
amindfv@gmail.com
-
Henning Thielemann
-
John Wiegley
-
M Farkas-Dyck
-
wren romano