Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthew de Detrich
    @mdedetrich
    That is however my view on it, I am just repeating what Seth is saying, which is that the stdlib should should contain at least one collection that satisfies these properties. Having more is overkill, but that isn’t the case here
    Julien Richard-Foy
    @julienrf
    I’ve added the following comment in the PR discussion, let me know if I forgot something. And feel free to give your opinion there too.
    Matthew de Detrich
    @mdedetrich
    Yup thats a good summary, thanks
    Matthew de Detrich
    @mdedetrich
    @julienrf Does it sound like a good idea to post this on reddit to get some more visibility?
    Julien Richard-Foy
    @julienrf
    Yeah, why not
    Princess | April
    @NthPortal
    personally, I'm in favour of having it in the stdlib, for the same reason as Seth
    Ichoran
    @Ichoran
    I also am in favor, for the same reason.
    Matthew de Detrich
    @mdedetrich
    @NthPortal Can you post your sentiment in the thread
    Would be good to get as many responses as possible
    Matthew de Detrich
    @mdedetrich
    Odd Möller
    @odd

    Hi all, every now and then I come accross the sentiment that you should never code against Seq but instead use a concrete collection such as List or Vector. The reasons given vary, but I most often see:

    1. You don't know whether it will be mutable or immutable
    2. You don't know whether it will be finite or infinite

    While 1. has been somewhat fixed with 2.13 (since the Seq type in the scala package object now points to immutable.Seq), number 2. still stands. Where separating finite and infinite collections ever considered for the strawman? And if so, what where the pros and cons?

    Harrison Houghton
    @hrhino
    I can add a third:
    1. you don't know the asymptotic performance of most operations (e.g., tail, +:, and last)
    Which, IMO, is the biggest
    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