On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge wrote:

On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood wrote:

...

`length :: [a] -> Word` (or things of that ilk) would be even more of a mistake, because type inference will spread that `Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me. I have in the past used Word for things that seemed like they should always be positive, and pretty quickly reverted back to a signed type. All you need is a subtraction anywhere and the chance of underflow is very high. And, as Ben said, it's easy for the "always positive" type to wind up in a domain where subtraction is valid due to type inference. The principled thing might be to make that a different type, but in practice that can be a lot of hassle so it often doesn't happen (do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength). It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance. Besides, nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal. Relatively weak +1 from me (I'm more enthusiastic about exporting the entirely of Intx/Wordx types via the prelude). John L.

Those would remain in Data.Int and Data.Word. -Edward On Wed, Aug 13, 2014 at 8:04 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

wait the proposal wasn't for including Intx and Wordx in prelude? ('cause I'd support that strongly! )

On Wed, Aug 13, 2014 at 7:25 PM, John Lato wrote:

...

On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge wrote:

...

On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood wrote:

...

`length :: [a] -> Word` (or things of that ilk) would be even more of a mistake, because type inference will spread that `Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me. I have in the past used Word for things that seemed like they should always be positive, and pretty quickly reverted back to a signed type. All you need is a subtraction anywhere and the chance of underflow is very high. And, as Ben said, it's easy for the "always positive" type to wind up in a domain where subtraction is valid due to type inference. The principled thing might be to make that a different type, but in practice that can be a lot of hassle so it often doesn't happen (do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength). It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance. Besides, nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal.

Relatively weak +1 from me (I'm more enthusiastic about exporting the entirely of Intx/Wordx types via the prelude).

John L.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sun, Aug 17, 2014 at 5:26 PM, Ben Millwood wrote:

On Wed, Aug 13, 2014 at 04:25:10PM -0700, John Lato wrote:

...

'Word' is usually a better choice than 'Int' when non-negative quantities (such as list lengths, bit or vector indices, or number of items in a container) need to be represented.

If we are not proposing to use it for general non-negative things, then, well, what on earth *is* it for? I mean, I imagine `length` wouldn't change either way, for compatibility reasons, but either we'd use it for something else, and be confronted with my argument, or we wouldn't, in which case the proposal isn't really doing much good.

Let me give some context here. I was thinking of the GHC primops for Array#s and ByteArray#s here, not changing anything e.g. that have to do with lists or the prelude. Another important use case is bit masks and general bit twiddling, which you often want to do with unsigned types.

I'm all in favor of more commutative rings with unity, but I'm pretty sure Int is one as well, Daniel Díaz Casanueva, as it is implemented by GHC. On Sun, Aug 17, 2014 at 1:09 PM, Daniel Díaz Casanueva wrote:

I am +1 for this proposal.

I just wanted to add one thing. Operations defined on Word are not non-sense or broken. In fact, IIRC, they obey the (commutative) ring axioms. Namely:

* Word is an abelian group with respect to addition (commutative monoid where every element has an inverse). * Word is a monoid with respect to multiplication. * Multiplication in Word distributes the sum.

Furthermore, it is commutative and unitary, with 1 being the multiplicative identity.

I have my doubts that we can say all these things of the type Int. Personally, I am not concerned about subtraction returning a bigger quantity: that's how modular arithmetic works and it's predictable. But I understand the point made in this thread.

Best regards, Daniel Díaz.

On Sun, Aug 17, 2014 at 5:26 PM, Ben Millwood wrote:

...

On Wed, Aug 13, 2014 at 04:25:10PM -0700, John Lato wrote:

...

On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge wrote:

...

On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood wrote:

...

`length :: [a] -> Word` (or things of that ilk) would be even more of a mistake, because type inference will spread that `Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me. I have in the past used Word for things that seemed like they should always be positive, and pretty quickly reverted back to a signed type. All you need is a subtraction anywhere and the chance of underflow is very high. And, as Ben said, it's easy for the "always positive" type to wind up in a domain where subtraction is valid due to type inference. The principled thing might be to make that a different type, but in practice that can be a lot of hassle so it often doesn't happen (do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength). It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance.

The option is already available, the proposal is to make it available in the Prelude, which to me is a matter of emphasis, and what we consider idiomatic or not. All this stuff about programmers taking on responsibilities is perfectly fine, but I think they ought to opt-in to that by importing Data.Word, rather than by having it implicitly available.

...

Besides, nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal.

Quote from the original proposal:

...

'Word' is usually a better choice than 'Int' when non-negative quantities (such as list lengths, bit or vector indices, or number of items in a container) need to be represented.

If we are not proposing to use it for general non-negative things, then, well, what on earth *is* it for? I mean, I imagine `length` wouldn't change either way, for compatibility reasons, but either we'd use it for something else, and be confronted with my argument, or we wouldn't, in which case the proposal isn't really doing much good.

I agree that there is often a need for values which must be non-negative. But if we decide we need that sort of thing, we ought to worry about what operations it should support and what they do in the case of underflow. It seems to me like the behaviour of Word is the least Haskelly of all the plausible options – not even a runtime error! – and should be confined only to those who know what they are doing.

...

Relatively weak +1 from me (I'm more enthusiastic about exporting the entirely of Intx/Wordx types via the prelude).

I'm actually less against WordX and friends because at least they have a precise specification and purpose. But they seem quite niche to me. What's so terrible about importing them before use?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sun, Aug 17, 2014 at 07:09:21PM +0200, Daniel Díaz Casanueva wrote:

I am +1 for this proposal.

I just wanted to add one thing. Operations defined on Word are not non-sense or broken. In fact, IIRC, they obey the (commutative) ring axioms. Namely:

* Word is an abelian group with respect to addition (commutative monoid where every element has an inverse). * Word is a monoid with respect to multiplication. * Multiplication in Word distributes the sum.

Furthermore, it is commutative and unitary, with 1 being the multiplicative identity.

This is all quite true. However, Word, while being a ring and being ordered, fails to be an ordered ring, in the sense that the ordering is not compatible with the ring operations, so there is some not-insignificant inconsistency there, e.g. it is not always the case that `n + 1 > n`. Moreover, Word, like Int, does not have a mandated standard width, so while it is always a commutative ring, *which* commutative ring it is is ambiguous. This latter point is a very strange one for those who believe that types should have a clear denotation! (All of those things are true of `Int` too, of course. But at least `Int` emulates `Integer` if your numbers are suitably small, which often they are. `Word`, on the other hand, places the threat of underflow *right there* next to zero, so the danger feels more difficult to avoid.) And anyway, behaviour that is law-abiding is not necessarily helpful. We have to ask ourselves what actual need is fulfilled by Word. It seems to me that it fails as a general type for non-negative integers, because it does not prevent subtraction or negation. It arguably has a place in GHC primops, which are exotic and dangerous things that mostly should be hidden from the casual user. It may or may not have its place in bit manipulation, which I have no complaints with but basically don't believe happens very often, and probably is better off with types with a clear, specified width, like Word32. What's left? To those enthusiastically +1-ing this proposal, how will it improve your lives?

I have my doubts that we can say all these things of the type Int. Personally, I am not concerned about subtraction returning a bigger quantity: that's how modular arithmetic works and it's predictable. But I understand the point made in this thread.

Best regards, Daniel Díaz.

On Sun, Aug 17, 2014 at 5:26 PM, Ben Millwood wrote:

...

On Wed, Aug 13, 2014 at 04:25:10PM -0700, John Lato wrote:

...

On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge wrote:

On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood

...

wrote:

...

`length :: [a] -> Word` (or things of that ilk) would be even more of a mistake, because type inference will spread that `Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me. I have in the past used Word for things that seemed like they should always be positive, and pretty quickly reverted back to a signed type. All you need is a subtraction anywhere and the chance of underflow is very high. And, as Ben said, it's easy for the "always positive" type to wind up in a domain where subtraction is valid due to type inference. The principled thing might be to make that a different type, but in practice that can be a lot of hassle so it often doesn't happen (do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength). It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance.

The option is already available, the proposal is to make it available in the Prelude, which to me is a matter of emphasis, and what we consider idiomatic or not. All this stuff about programmers taking on responsibilities is perfectly fine, but I think they ought to opt-in to that by importing Data.Word, rather than by having it implicitly available.

Besides,

...

nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal.

Quote from the original proposal:

'Word' is usually a better choice than 'Int' when non-negative quantities

...

(such as list lengths, bit or vector indices, or number of items in a container) need to be represented.

If we are not proposing to use it for general non-negative things, then, well, what on earth *is* it for? I mean, I imagine `length` wouldn't change either way, for compatibility reasons, but either we'd use it for something else, and be confronted with my argument, or we wouldn't, in which case the proposal isn't really doing much good.

I agree that there is often a need for values which must be non-negative. But if we decide we need that sort of thing, we ought to worry about what operations it should support and what they do in the case of underflow. It seems to me like the behaviour of Word is the least Haskelly of all the plausible options – not even a runtime error! – and should be confined only to those who know what they are doing.

Relatively weak +1 from me (I'm more enthusiastic about exporting the

...

entirely of Intx/Wordx types via the prelude).

I'm actually less against WordX and friends because at least they have a precise specification and purpose. But they seem quite niche to me. What's so terrible about importing them before use?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sun, Aug 24, 2014 at 2:08 PM, Ben Millwood wrote:

What's left? To those enthusiastically +1-ing this proposal, how will it improve your lives?

Unsigned fixed-width integers appear everywhere in programming and algorithms. Haskell is to my knowledge the only language that doesn't expose such a type next to its signed version.

On Sunday, August 24, 2014, Bardur Arantsson wrote:

On 2014-08-24 17:27, Johan Tibell wrote:

...

On Sun, Aug 24, 2014 at 2:08 PM, Ben Millwood javascript:;> wrote:

...

What's left? To those enthusiastically +1-ing this proposal, how will it improve your lives?

Unsigned fixed-width integers appear everywhere in programming and algorithms. Haskell is to my knowledge the only language that doesn't expose such a type next to its signed version.

Java is a notable exception here. Usually the omission leads to pain, but it has to be said that it's mostly just when interfacing with C and/or in parsing binary formats.

Python, JavaScript, Erlang, Ruby, Lua are other exceptions that do not have built-in fixed width wrap-around integer types or unsigned numbers of any kind. Parsing isn't a problem, wraparound is usually emulated with bitwise and. Gets ugly. -bob

On Tue, Aug 26, 2014 at 1:56 PM, Malcolm Wallace wrote:

I deeply appreciate the need for unsigned fixed-width integers, but I oppose the exposure of Word, because there are no guarantees on what its fixed width is. Hence, you cannot know when it will be dangerous to use. By all means expose Word8, Word16, Word32, Word64 instead. Their names provide a greater hint to the programmer that they have limitations, and that the programmer should check carefully whether those limitations are appropriate for their usage.

The problem is that now you cannot express "the largest fixed-sized, unsigned int that can be handled efficiently". Word64 is terribly slow on 32-bit machines.

Frankly, I am with Ben; a -0.5 from me. Machine integers have the size of the addressable main memory, so they should be used (exclusively?) for quantities that are limited by the size of the memory, like the mentioned indices into data structures like vectors or arrays. With Word I can address as many objects as my machine can hold bytes. However, the objects are usually not bytes, but words themselves. Thus, Int, which is only one bit short of Word, is as good as Word as an index type. Further, Int supports subtraction. I do not know what Word would be good for to the amount that it deserves a place in Prelude. Further, the absence of Word takes the futile conflict off my mind: "Should I use Int or Word?" If people feel very strongly about Word in Prelude, I do not want to be in the way, but I see no use for it (except maybe in OS-level programming, bit, protocols, FFI and the like). On 17.08.2014 17:26, Ben Millwood wrote:

On Wed, Aug 13, 2014 at 04:25:10PM -0700, John Lato wrote:

...

On Wed, Aug 13, 2014 at 4:05 PM, Evan Laforge wrote:

...

On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood wrote:

...

`length :: [a] -> Word` (or things of that ilk) would be even more of a mistake, because type inference will spread that `Word` everywhere, and `2 - 3 :: Word` is catastrophically wrong.

This is a pretty convincing argument for me. I have in the past used Word for things that seemed like they should always be positive, and pretty quickly reverted back to a signed type. All you need is a subtraction anywhere and the chance of underflow is very high. And, as Ben said, it's easy for the "always positive" type to wind up in a domain where subtraction is valid due to type inference. The principled thing might be to make that a different type, but in practice that can be a lot of hassle so it often doesn't happen (do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

I agree it would be wrong to have `length` return a Word unconditionally, but I don't think it's a mistake in general to have that option available (i.e. genericLength). It just means that the programmer is taking on some responsibilities manually instead of leveraging the type system, but sometimes that's the only way to get the desired performance.

The option is already available, the proposal is to make it available in the Prelude, which to me is a matter of emphasis, and what we consider idiomatic or not. All this stuff about programmers taking on responsibilities is perfectly fine, but I think they ought to opt-in to that by importing Data.Word, rather than by having it implicitly available.

...

Besides, nobody is actually proposing that `length` return a Word, so I don't find this argument relevant to the proposal.

Quote from the original proposal:

...

'Word' is usually a better choice than 'Int' when non-negative quantities (such as list lengths, bit or vector indices, or number of items in a container) need to be represented.

If we are not proposing to use it for general non-negative things, then, well, what on earth *is* it for? I mean, I imagine `length` wouldn't change either way, for compatibility reasons, but either we'd use it for something else, and be confronted with my argument, or we wouldn't, in which case the proposal isn't really doing much good.

I agree that there is often a need for values which must be non-negative. But if we decide we need that sort of thing, we ought to worry about what operations it should support and what they do in the case of underflow. It seems to me like the behaviour of Word is the least Haskelly of all the plausible options – not even a runtime error! – and should be confined only to those who know what they are doing.

...

Relatively weak +1 from me (I'm more enthusiastic about exporting the entirely of Intx/Wordx types via the prelude).

I'm actually less against WordX and friends because at least they have a precise specification and purpose. But they seem quite niche to me. What's so terrible about importing them before use? _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Am 14.08.2014 um 01:05 schrieb Evan Laforge:

(do you use NonEmpty everywhere possible? always have separate types for absolute and relative measures? sometimes it's not worth the clutter).

Would be nice to have these without a lot of clutter, maybe Liquid Haskell will provide a solution?