The distinction between the start and the end of a List/Array is really arbitrary. You could consider a List to grow to the right instead of the left by just flipping the List constructors and functions:
head :: tail --> front :: last
etc, and then suddenly Lists are really fast at adding elements to the end!
Because of this, I don't think the distinction between Arrays being fast at the end and Lists being fast at the start is necessary. Really they're both fast at adding to any one predetermined end, with List being a constant factor faster (from the benchmarks, seemingly 7x). This makes Lists slightly better for an algorithm that needs to grow or shrink a List at only one end. For anything else, Lists are usually worse.
If the solution to having fast insertions at either end of an Array is RRB trees, aren't we going in circles? This is the implementation Elm has in 0.18 (though it could do with some work).
I wouldn’t say we’re going in circles. The 0.19 implementation is a complete re-write, because the 0.18 implentation is undocumented an buggy. It was always planned that it would eventually evolve into an RRB tree in time.
I think i’ve mentioned it in my status updates in the elm-dev mailing list. It’s not secret by any means, but i’m not the authority on what makes it into Elm, so I don’t mention it often either.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The distinction between the start and the end of a List/Array is really arbitrary. You could consider a List to grow to the right instead of the left by just flipping the List constructors and functions:
head :: tail --> front :: last
etc, and then suddenly Lists are really fast at adding elements to the end!
Because of this, I don't think the distinction between Arrays being fast at the end and Lists being fast at the start is necessary. Really they're both fast at adding to any one predetermined end, with List being a constant factor faster (from the benchmarks, seemingly 7x). This makes Lists slightly better for an algorithm that needs to grow or shrink a List at only one end. For anything else, Lists are usually worse.
If the solution to having fast insertions at either end of an Array is RRB trees, aren't we going in circles? This is the implementation Elm has in 0.18 (though it could do with some work).
I wouldn’t say we’re going in circles. The 0.19 implementation is a complete re-write, because the 0.18 implentation is undocumented an buggy. It was always planned that it would eventually evolve into an RRB tree in time.
Fair enough. Obviously I'm not informed about those plans - they're not public I'm assuming.
I think i’ve mentioned it in my status updates in the elm-dev mailing list. It’s not secret by any means, but i’m not the authority on what makes it into Elm, so I don’t mention it often either.