Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Harrison Houghton
    @hrhino
    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
    but it could just as well be sizeCompare
    Ichoran
    @Ichoran
    Yup.
    Princess | April
    @NthPortal
    arguably, it would be better to have it for Iterable
    Ichoran
    @Ichoran
    I'm happy with it either way. Usually for lengthCompare I'd be thinking about taking the same amount of stuff again.
    Whereas compareSize(xs) I'd likely use in other ways.
    But I can see it going either way. @julienrf and/or @szeiger -- what do you think?
    Princess | April
    @NthPortal
    do you have a preference for compareSize(Iterable) over sizeCompare(Iterable), btw? just thinking about consistency
    Ichoran
    @Ichoran
    I think sizeCompare is grammatically awkward in English. compareSize is better, but doesn't tell me anything about whether the argument is a size or a thing that has a size. Maybe compareSizeTo?
    I like the xs.lengthIs < 0 thing because the name suggests the usage without having to consult an API.
    Princess | April
    @NthPortal
    I haven't figured out a way to extend that usage to other collections, sadly
    should StringOps define lengthCompare?
    Ichoran
    @Ichoran
    Meh. I don't know. I am very uneasy about the whole situation with ArrayOps and StringOps. I guess the canonical answer is "yes, it should implement everything that collections with IndexedSeqOps do"?
    Matthew de Detrich
    @mdedetrich

    @Ichoran

    (the distinction being that size is not meant to imply a consistent ordering, whereas length is).

    I didn’t know this distinction exists, I also don’t know how consistant this is. All I can say from my perspective, from a language PoV length vs size mean basically the same thing in this context and they say nothing about whether the collection is ordered or not

    I wish that this distinction would be removed since its confusing and you can tell whether or not a collection is ordered by its type (which is themore idiomatic Scala way of doing things anyways)
    nafg
    @nafg
    Is it true that the new collections design failed to significantly reduce the size of scala.js programs?