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 <***@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

> <***@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 <***@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 <***@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 <***@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 <

> ***@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

> >>>> > ***@haskell.org

> >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

> >>>> _______________________________________________

> >>>> Libraries mailing list

> >>>> ***@haskell.org

> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

> >>

> >> _______________________________________________

> >> Libraries mailing list

> >> ***@haskell.org

> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

> >

> > _______________________________________________

> > Libraries mailing list

> > ***@haskell.org

> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

> _______________________________________________

> Libraries mailing list

> ***@haskell.org

> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

>