Proposal: Export Data.Word.Word from Prelude

[Andreas Abel]

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 <qdunkan at gmail.com> wrote:
>>
>>> On Wed, Aug 13, 2014 at 3:06 PM, Ben Millwood <haskell at benmachine.co.uk>
>>> 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 at 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 at gu.se
http://www2.tcs.ifi.lmu.de/~abel/