Yes please. On Fri, Jul 2, 2021 at 8:43 AM chessai wrote:

+1, along with Int{8,16,32,64} & Word{8,16,32,64}

On Fri, Jul 2, 2021, 10:27 Carter Schonwald wrote:

...

This seems long overdue and aside from some redundant import warnings likely low breakage risk

Thoughts? _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Not to derail, but I am +1 on the original suggestion, but +10 on Int* and Word* On Fri, 2 Jul 2021, at 4:42 PM, chessai wrote:

+1, along with Int{8,16,32,64} & Word{8,16,32,64}

On Fri, Jul 2, 2021, 10:27 Carter Schonwald wrote:

...

This seems long overdue and aside from some redundant import warnings likely low breakage risk

Thoughts? _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Fri, 2 Jul 2021, at 4:56 PM, Henning Thielemann wrote:

On Fri, 2 Jul 2021, Oliver Charles wrote:

...

Not to derail, but I am +1 on the original suggestion, but +10 on Int* and Word*

Can people please not only say +1, but also tell some reasons?

Natural is frequently a much more correct type than Int or Integer, as it naturally (ha) rules out needing to think about negative cases. Int* and Word* are frequently what I need to ultimately consume or produce. I don't agree they are "low-level", unless we consider any boundary to be low-level. But even then, if I ultimately have to produce Int64, I don't want to overflow a million miles away and then suddenly fail at the boundary. Int64 _is_ the correct type throughout the whole system I'm building. Unless my whole system is low-level, but that's a subjective judgement. I also don't think we can consider Int any less low-level - it's still bounded, but in a sense even less predictably due to varying depending on the underlying architecture. Due to needing them frequently, I just find it tedious to have to import them every time when they are perfectly uncontroversial (well, to me, anyway). Ollie

This is a good point were we adding it to base. It’s already in base and widely useful! That’s a good motivation to add for fixing num and friends. But that’s not even a new problem for num instances in base. Reexport it from prelude doesn’t change that. Just improves the ergonomics for using a really nice type for both pedagogy and prototyping! I also like how natural throws an error on underflow. On Fri, Jul 2, 2021 at 12:54 PM David Feuer wrote:

I'm going to play devil's advocate and say no. I believe Num instances should be rings under + and *. Natural is an instance of Num but is not a ring.

On Fri, Jul 2, 2021, 11:26 AM Carter Schonwald wrote:

...

This seems long overdue and aside from some redundant import warnings likely low breakage risk

Thoughts? _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Yeah. This is a good point. It’s worth doing a grep of definitions in hackage to see wha the blast radius is ofothwreiee working code. If there’s no breakage risk for old code, that’s a point in favor of inclusion of Natural in prelude rather than just being an extra import from base. If not, it’s a cost that must be weighed. On Wed, Jul 7, 2021 at 3:09 PM Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Wed, 7 Jul 2021, Ken T Takusagawa wrote:

...

On Fri, 2 Jul 2021, Carter Schonwald wrote:

...

This seems long overdue and aside from some redundant import warnings likely low breakage risk

Am I understanding correctly that this will cause any code that defines its own type named Natural to break?

right

...

And the proper workaround will be import Prelude hiding(Natural) ?

this would work, but would cause warnings in older Prelude versions