Proposal: Export Data.Word.Word from Prelude

Sun Aug 17 20:04:25 UTC 2014

David, I didn't want to say it isn't. I just wasn't sure about that. But,
after some tests, it seems I can't find a counterexample. Which is good
news! :)

Regards,
Daniel Díaz.

On Sun, Aug 17, 2014 at 9:31 PM, David Feuer <david.feuer at gmail.com> wrote:

> 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
> <dhelta.diaz at gmail.com> 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 <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
> >
> >
> >
> > _______________________________________________
> > 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/8694eab1/attachment.html>