Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Odd Möller
    @odd
    @hrhino yeah, that too of course (although you could use IndexedSeq or LinearSeq instead if you want to know more about the performance characteristics).
    Harrison Houghton
    @hrhino
    Right, but you asked about Seq :wink:
    I think LinearSeq and IndexedSeq are mostly pretty good
    Odd Möller
    @odd
    @hrhino touché
    Ichoran
    @Ichoran
    I think Seq is fine when you don't care.
    Stream will probably break everything. (Now, LazyList.) Maybe we should remove it from the hierarchy. Make it an Iterable, if even that.
    Harrison Houghton
    @hrhino
    Yeah, if you're going to iterate over it.
    @Ichoran working on super-lazy list, I think it shouldn't be part of hierarchy except for Iterable, too
    Ichoran
    @Ichoran
    As I explained last time, Seq promises a stable iteration order but Iterable does not.
    Harrison Houghton
    @hrhino
    you can have lazyLines that does no IO, but lazyLines.drop(1) will
    Ichoran
    @Ichoran
    That's the essential difference: the elements have a one-to-one correspondence with 0, 1, ...
    Whereas with Iterable if it happens to iterate in the same order, that's its choice. You aren't promised that this will be the case.
    So a.take(a.indexWhere(p)) works if a is a Seq but not an Iterable
    Princess | April
    @NthPortal
    @hrhino hopefully drop is fully lazy in the new implementation?
    Harrison Houghton
    @hrhino
    it's not.
    I will need to basically reimplement all of the LinearSeqOps
    and it doesn't feel right.
    Princess | April
    @NthPortal
    hmm
    I think I agree with whoever said it that an implementation using a by-name State like Sébastien suggested would probably be better in that regard
    Harrison Houghton
    @hrhino
    I did that.
    I haven't pushed it. I agree with it, though
    The problem stands, that the LinearSeqOps's drop requires an immediate isEmpty call, which forces the LazyList.
    Princess | April
    @NthPortal
    hmm
    it doesn't use View.Drop or something?
    Harrison Houghton
    @hrhino
    Nope
    Honestly I'm okay with it not.
    LazyList, if it's meant to be fully lazy, should be pretty special.
    I think I'm going to make it implement as little as possible.
    The danger is inheriting accidentally-strict ops from Seq/LinearSeq.
    I did expect that most ops would be using views, but evidently not.
    Princess | April
    @NthPortal
    I thought everything was supposed to be lazy by default specifically to avoid this problem
    Harrison Houghton
    @hrhino
    It's not lazy enough, I guess
    drop on LinearSeq starts by checking isEmpty
    Matthew de Detrich
    @mdedetrich
    @NthPortal This is a general problem with strict by default languages is that its very hard to make everything fully lazy. Languages that are lazy by default have the converse problem (i.e. its hard to make non trivial data structures fully strict in Haskell).
    Ichoran
    @Ichoran
    @hrhino - The problem with making everything using views is that then everything is slow.
    Matthew de Detrich
    @mdedetrich
    @Ichoran I thought that was the general purpose of the collections redesign though, make everything lazy and overwrite for strict collections
    i.e. make the default correct but slow
    Ichoran
    @Ichoran
    Yeah, more or less. LazyList just sits in a weird place in the hierarchy, surrounded by eager collections.
    Matthew de Detrich
    @mdedetrich
    Lazy people never make good friends with strict people….
    Ichoran
    @Ichoran
    Anyway, that wasn't one of the primary goals, but it was a secondary goal.
    Matthew de Detrich
    @mdedetrich
    I think there were a lot of primary goals, and this is one of them
    Ichoran
    @Ichoran
    That's not what I remember; I think that having fully-functional views was a primary goal, though, and it's pretty hard to have that if the hierarchy is strict at the top.
    Princess | April
    @NthPortal
    someone brought up on the lengthCompare ticket that besides having nicer syntax for that, it would be nice to have a method to compare Seq lengths, something like def lengthCompare(that: Seq[_]): Int
    is it too late in the release cycle to add that?
    Ichoran
    @Ichoran
    I would call that compareSize and put it on Iterable.
    Princess | April
    @NthPortal
    :+1:
    Ichoran
    @Ichoran
    There's nothing Seq-specific about that method.
    Princess | April
    @NthPortal
    to be fair, there's nothing Seq specific about lengthCompare(Int):Int either
    Ichoran
    @Ichoran
    Except that "length" is a Seq thing (the distinction being that size is not meant to imply a consistent ordering, whereas length is).
    Princess | April
    @NthPortal
    fair