scala.mutable.Vector
based on trie structure so it's technically much more complex than java.util.ArrayList
. This complexity means that bunch of List
s sharing commong suffixes could be more lightweight than bunch of Vector
s sharing common prefixes.
That property means a lot in functional style where you often have a lot of operations which take collection and return its copy modified just a bit, like stack. Appending to large Vector
could generate several new objects, prepeding to List
- always one.
List
is very simple to understand and reason about. It's just ::
or Nil
.
Implementation of Vector
is pretty much hidden, it has "dirty" optimisations and could be matched preferredly via seq extractors which refers to hidden optimized drops
Random haskell developer probably wants Stream
to be default Seq
instead of List
. Some scalaz
lover - wants more some symmetric Sequence exported to std lib.
You can not change choice of scala.Seq.apply
becasuse it based on List
as result of ListBuffer
chosen newBuilder
implementation. However you can write your own similar Seq
factory like
object Seq extends SeqFactory[Seq] {
implicit def canBuildFrom[A]: CanBuildFrom[Coll, A, Seq[A]] = ReusableCBF.asInstanceOf[GenericCanBuildFrom[A]]
def newBuilder[A]: Builder[A, Seq[A]] = new VectorBuilder[A]
}
So summarizing:
- Linked list is historically most dominant collection type in functional languages
- Another sequence type could be much more useful in another domain
- You can not "switch"
scala.Seq.apply
to another generic type. But can import or create another object under name Seq
.
I personally find Vector(...)
form more useful and concise than IndexedSeq(...)
. Same for List(...)
instead of Seq(...)
or LinearSeq(...)
.