Proposal: Export Data.Word.Word from Prelude

Daniel Díaz Casanueva dhelta.diaz at gmail.com
Sun Aug 17 17:09:21 UTC 2014


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 <haskell at benmachine.co.uk>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140817/e3633b73/attachment.html>


More information about the Libraries mailing list