Generalizing some type signatures involving Int

[David Feuer]

Data.Sequence actually doesn't support anything outside the Int range. It
could, at a small cost. We perform some range checks cheaply using unsigned
comparisons. We'd have to stop doing that to allow sequences to be just a
tad more absurdly large. Since that's not often useful, sequences are
currently limited to lengths of maxBound @Int.

On Thu, Nov 15, 2018, 5:53 PM Zemyla <zemyla at gmail.com wrote:

> It's not actually impossible to have an in RAM structure that exceeds
> the largest positive value for Int. Data.Sequence.replicate does it by
> exploiting sharing. replicate n a uses O(lg n) space.
>
> > length $ let x = Data.Sequence.Replicate maxBound 'a' :> 'b' in mappend
> x x
> 0
>
> Also, I really would like to have all the length and count-based
> functions in base, containers, etc. take or return Words, but there's
> way too much inertia behind Ints, even if it means you have to check
> for negative numbers (which really runs counter to the main thesis
> behind Haskell; i.e. have your types say what you mean).
>
> On Thu, Nov 15, 2018 at 12:30 AM Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > Agreed.
> >
> > As David and Eric both say:
> > For in heap / memory size structures, it’s impossible to ever have an in
> ram structure that exceeds the largest positive value for Int.  And ghc is
> also quite good at optimizing int.
> >
> > 1) what is your application domain / context ?
> >
> > 2) all of these are implementable in user space, what design /
> implementation experiments have you done ?
> >
> > It’s worth mentioning that RULES style optimization in this case would
> only run AFTER it’s been specialized to a concrete type.  And that short of
> lots of specialize pragmas or inlining , the generic code will thusly miss
> out on all sorts of unboxong etc.
> >
> > On Tue, Nov 13, 2018 at 10:31 PM David Feuer <david.feuer at gmail.com>
> wrote:
> >>
> >> That won't help whatsoever in most cases. The matter has been discussed
> several times with no progress. If you want to add RULES for Int8, Int16,
> ..., Word, Word8, ..., and Natural to match the ones for Int and Integer,
> that would make sense, but the basic problem will remain for unmentioned
> types.
> >>
> >> On Tue, Nov 13, 2018, 10:24 PM Vanessa McHale <vanessa.mchale at iohk.io
> wrote:
> >>>
> >>> This is perhaps not the right place, but if there are benchmarks
> proving that genericLength is slower than it should be, it should be easy
> to add a SPECIALIZE pragma.
> >>>
> >>> On 11/13/18 9:13 PM, David Feuer wrote:
> >>>
> >>> genericLength is extremely inefficient for typical numeric types. Int
> is a rather sad type for these things; it really should be Word. But that
> may not be worth fixing.
> >>>
> >>> On Tue, Nov 13, 2018, 9:51 PM Evan Laforge <qdunkan at gmail.com wrote:
> >>>>
> >>>> You can already get these as Data.List.genericLength and
> >>>> Data.List.genericReplicate
> >>>>
> >>>> As for changing the prelude ones, this would probably cause a lot of
> >>>> busywork.  Where I work we compile with -Werror and -Wtype-defaults,
> >>>> so a lot of places might have to get type annotations.
> >>>> On Tue, Nov 13, 2018 at 5:19 PM Vanessa McHale <
> vanessa.mchale at iohk.io> wrote:
> >>>> >
> >>>> > Would it be possible to generalize replicate and length to have type
> >>>> > signatures
> >>>> >
> >>>> > replicate :: Integral a => a -> b -> [b]
> >>>> >
> >>>> > and
> >>>> >
> >>>> > length :: (Integral a, Foldable t) => t b -> a
> >>>> >
> >>>> > ?
> >>>> >
> >>>> > There have been a few instances where such a thing would have been
> >>>> > useful to me.
> >>>> >
> >>>> > Cheers
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Libraries mailing list
> >>>> > Libraries at haskell.org
> >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181115/0e76d33a/attachment.html>