An immutable array.

Supports efficient indexed access and has a small memory footprint.

A class for immutable bitsets.

Bitsets are sets of non-negative integers which are represented as variable-size arrays of bits packed into 64-bit words. The lower bound of memory footprint of a bitset is determined by the largest number stored in it.

This class implements immutable maps using a Compressed Hash-Array Mapped Prefix-tree. See paper https://michael.steindorfer.name/publications/oopsla15.pdf for more details.

This class implements immutable sets using a Compressed Hash-Array Mapped Prefix-tree. See paper https://michael.steindorfer.name/publications/oopsla15.pdf for more details.

Specialised immutable map structure for integer keys, based on Fast Mergeable Integer Maps by Okasaki and Gill. Essentially a trie based on binary digits of the integers.

Note: This class is as of 2.8 largely superseded by HashMap.

A trait for collections that are guaranteed immutable.

This class implements an immutable linked list. We call it "lazy" because it computes its elements only when they are needed.

Elements are memoized; that is, the value of each element is computed at most once.

Elements are computed in-order and are never skipped. In other words, accessing the tail causes the head to be computed first.

How lazy is a LazyList? When you have a value of type LazyList, you don't know yet whether the list is empty or not. If you learn that it is non-empty, then you also know that the head has been computed. But the tail is itself a LazyList, whose emptiness-or-not might remain undetermined.

A LazyList may be infinite. For example, LazyList.from(0) contains all of the natural numbers 0, 1, 2, and so on. For infinite sequences, some methods (such as count, sum, max or min) will not terminate.

Here is an example:

import scala.math.BigInt
object Main extends App {
  val fibs: LazyList[BigInt] =
    BigInt(0) #:: BigInt(1) #:: fibs.zip(fibs.tail).map{ n => n._1 + n._2 }
  fibs.take(5).foreach(println)
}

// prints
//
// 0
// 1
// 1
// 2
// 3

To illustrate, let's add some output to the definition fibs, so we see what's going on.

import scala.math.BigInt
object Main extends App {
  val fibs: LazyList[BigInt] =
    BigInt(0) #:: BigInt(1) #::
      fibs.zip(fibs.tail).map{ n =>
        println(s"Adding ${n._1} and ${n._2}")
        n._1 + n._2
      }
  fibs.take(5).foreach(println)
  fibs.take(6).foreach(println)
}

// prints
//
// 0
// 1
// Adding 0 and 1
// 1
// Adding 1 and 1
// 2
// Adding 1 and 2
// 3

// And then prints
//
// 0
// 1
// 1
// 2
// 3
// Adding 2 and 3
// 5

Note that the definition of fibs uses val not def. The memoization of the LazyList requires us to have somewhere to store the information and a val allows us to do that.

Further remarks about the semantics of LazyList:

• Though the LazyList changes as it is accessed, this does not contradict its immutability. Once the values are memoized they do not change. Values that have yet to be memoized still "exist", they simply haven't been computed yet.
• One must be cautious of memoization; it can eat up memory if you're not careful. That's because memoization of the LazyList creates a structure much like scala.collection.immutable.List. As long as something is holding on to the head, the head holds on to the tail, and so on recursively. If, on the other hand, there is nothing holding on to the head (e.g. if we used def to define the LazyList) then once it is no longer being used directly, it disappears.
• Note that some operations, including drop, dropWhile, flatMap or collect may process a large number of intermediate elements before returning.

Here's another example. Let's start with the natural numbers and iterate over them.

// We'll start with a silly iteration
def loop(s: String, i: Int, iter: Iterator[Int]): Unit = {
  // Stop after 200,000
  if (i < 200001) {
    if (i % 50000 == 0) println(s + i)
    loop(s, iter.next(), iter)
  }
}

// Our first LazyList definition will be a val definition
val lazylist1: LazyList[Int] = {
  def loop(v: Int): LazyList[Int] = v #:: loop(v + 1)
  loop(0)
}

// Because lazylist1 is a val, everything that the iterator produces is held
// by virtue of the fact that the head of the LazyList is held in lazylist1
val it1 = lazylist1.iterator
loop("Iterator1: ", it1.next(), it1)

// We can redefine this LazyList such that all we have is the Iterator left
// and allow the LazyList to be garbage collected as required.  Using a def
// to provide the LazyList ensures that no val is holding onto the head as
// is the case with lazylist1
def lazylist2: LazyList[Int] = {
  def loop(v: Int): LazyList[Int] = v #:: loop(v + 1)
  loop(0)
}
val it2 = lazylist2.iterator
loop("Iterator2: ", it2.next(), it2)

// And, of course, we don't actually need a LazyList at all for such a simple
// problem.  There's no reason to use a LazyList if you don't actually need
// one.
val it3 = new Iterator[Int] {
  var i = -1
  def hasNext = true
  def next(): Int = { i += 1; i }
}
loop("Iterator3: ", it3.next(), it3)

• In the fibs example earlier, the fact that tail works at all is of interest. fibs has an initial (0, 1, LazyList(...)), so tail is deterministic. If we defined fibs such that only 0 were concretely known, then the act of determining tail would require the evaluation of tail, so the computation would be unable to progress, as in this code:

// The first time we try to access the tail we're going to need more
// information which will require us to recurse, which will require us to
// recurse, which...
lazy val sov: LazyList[Vector[Int]] = Vector(0) #:: sov.zip(sov.tail).map { n => n._1 ++ n._2 }

The definition of fibs above creates a larger number of objects than necessary depending on how you might want to implement it. The following implementation provides a more "cost effective" implementation due to the fact that it has a more direct route to the numbers themselves:

lazy val fib: LazyList[Int] = {
  def loop(h: Int, n: Int): LazyList[Int] = h #:: loop(n, h + n)
  loop(1, 1)
}

The head, the tail and whether the list is empty or not can be initially unknown. Once any of those are evaluated, they are all known, though if the tail is built with #:: or #:::, it's content still isn't evaluated. Instead, evaluating the tails content is deferred until the tails empty status, head or tail is evaluated.

Delaying the evaluation of whether a LazyList is empty or not until it's needed allows LazyList to not eagerly evaluate any elements on a call to filter.

Only when it's further evaluated (which may be never!) any of the elements gets forced.

for example:

def tailWithSideEffect: LazyList[Nothing] = {
  println("getting empty LazyList")
  LazyList.empty
}

val emptyTail = tailWithSideEffect // prints "getting empty LazyList"

val suspended = 1 #:: tailWithSideEffect // doesn't print anything
val tail = suspended.tail // although the tail is evaluated, *still* nothing is yet printed
val filtered = tail.filter(_ => false) // still nothing is printed
filtered.isEmpty // prints "getting empty LazyList"

A class for immutable linked lists representing ordered collections of elements of type A.

This class comes with two implementing case classes scala.Nil and scala.:: that implement the abstract members isEmpty, head and tail.

This class is optimal for last-in-first-out (LIFO), stack-like access patterns. If you need another access pattern, for example, random access or FIFO, consider using a collection more suited to this than List.

Performance

Time: List has O(1) prepend and head/tail access. Most other operations are O(n) on the number of elements in the list. This includes the index-based lookup of elements, length, append and reverse.

Space: List implements structural sharing of the tail list. This means that many operations are either zero- or constant-memory cost.

val mainList = List(3, 2, 1)
val with4 =    4 :: mainList  // re-uses mainList, costs one :: instance
val with42 =   42 :: mainList // also re-uses mainList, cost one :: instance
val shorter =  mainList.tail  // costs nothing as it uses the same 2::1::Nil instances as mainList

This class implements immutable maps using a list-based data structure. List map iterators and traversal methods visit key-value pairs in the order they were first inserted.

Entries are stored internally in reversed insertion order, which means the newest key is at the head of the list. As such, methods such as head and tail are O(n), while last and init are O(1). Other operations, such as inserting or removing entries, are also O(n), which makes this collection suitable only for a small number of elements.

Instances of ListMap represent empty maps; they can be either created by calling the constructor directly, or by applying the function ListMap.empty.

This class implements immutable sets using a list-based data structure. List set iterators and traversal methods visit elements in the order they were first inserted.

Elements are stored internally in reversed insertion order, which means the newest element is at the head of the list. As such, methods such as head and tail are O(n), while last and init are O(1). Other operations, such as inserting or removing entries, are also O(n), which makes this collection suitable only for a small number of elements.

Instances of ListSet represent empty sets; they can be either created by calling the constructor directly, or by applying the function ListSet.empty.

Specialised immutable map structure for long keys, based on Fast Mergeable Long Maps by Okasaki and Gill. Essentially a trie based on binary digits of the integers.

Note: This class is as of 2.8 largely superseded by HashMap.

NumericRange is a more generic version of the Range class which works with arbitrary types. It must be supplied with an Integral implementation of the range type.

Factories for likely types include Range.BigInt, Range.Long, and Range.BigDecimal. Range.Int exists for completeness, but the Int-based scala.Range should be more performant.

val r1 = Range(0, 100, 1)
val veryBig = Int.MaxValue.toLong + 1
val r2 = Range.Long(veryBig, veryBig + 100, 1)
assert(r1 sameElements r2.map(_ - veryBig))

Queue objects implement data structures that allow to insert and retrieve elements in a first-in-first-out (FIFO) manner.

Queue is implemented as a pair of Lists, one containing the in elements and the other the out elements. Elements are added to the in list and removed from the out list. When the out list runs dry, the queue is pivoted by replacing the out list by in.reverse, and in by Nil.

Adding items to the queue always has cost O(1). Removing items has cost O(1), except in the case where a pivot is required, in which case, a cost of O(n) is incurred, where n is the number of elements in the queue. When this happens, n remove operations with O(1) cost are guaranteed. Removing an item is on average O(1).

The Range class represents integer values in range [start;end) with non-zero step value step. It's a special case of an indexed sequence. For example:

val r1 = 0 until 10
val r2 = r1.start until r1.end by r1.step + 1
println(r2.length) // = 5

Ranges that contain more than Int.MaxValue elements can be created, but these overfull ranges have only limited capabilities. Any method that could require a collection of over Int.MaxValue length to be created, or could be asked to index beyond Int.MaxValue elements will throw an exception. Overfull ranges can safely be reduced in size by changing the step size (e.g. by 3) or taking/dropping elements. contains, equals, and access to the ends of the range (head, last, tail, init) are also permitted on overfull ranges.

A generic trait for ordered immutable maps. Concrete classes have to provide functionality for the abstract methods in SeqMap.

Note that when checking for equality SeqMap does not take into account ordering.

An immutable map whose key-value pairs are sorted according to an scala.math.Ordering on the keys.

Allows for range queries to be performed on its keys, and implementations must guarantee that traversal happens in sorted order, according to the map's scala.math.Ordering.

An immutable SortedMap whose values are stored in a red-black tree.

This class is optimal when range queries will be performed, or when traversal in order of an ordering is desired. If you only need key lookups, and don't care in which order key-values are traversed in, consider using * scala.collection.immutable.HashMap, which will generally have better performance. If you need insertion order, consider a * scala.collection.immutable.SeqMap, which does not need to have an ordering supplied.

This class implements an immutable map that preserves order using a hash map for the key to value mapping to provide efficient lookup, and a tree for the ordering of the keys to provide efficient insertion/modification order traversal and destructuring.

By default insertion order (TreeSeqMap.OrderBy.Insertion) is used, but modification order (TreeSeqMap.OrderBy.Modification) can be used instead if so specified at creation.

The orderingBy(orderBy: TreeSeqMap.OrderBy): TreeSeqMap[K, V] method can be used to switch to the specified ordering for the returned map.

A key can be manually refreshed (i.e. placed at the end) via the refresh(key: K): TreeSeqMap[K, V] method (regardless of the ordering in use).

Internally, an ordinal counter is increased for each insertion/modification and then the current ordinal is used as key in the tree map. After 2³² insertions/modifications the entire map is copied (thus resetting the ordinal counter).

This class implements immutable sorted sets using a tree.

Vector is a general-purpose, immutable data structure. It provides random access and updates in O(log n) time, as well as very fast append/prepend/tail/init (amortized O(1), worst case O(log n)). Because vectors strike a good balance between fast random selections and fast random functional updates, they are currently the default implementation of immutable indexed sequences.

Vectors are implemented by radix-balanced finger trees of width 32. There is a separate subclass for each level (0 to 6, with 0 being the empty vector and 6 a tree with a maximum width of 64 at the top level).

Tree balancing: - Only the first dimension of an array may have a size < WIDTH - In a data (central) array the first dimension may be up to WIDTH-2 long, in prefix1 and suffix1 up to WIDTH, and in other prefix and suffix arrays up to WIDTH-1 - prefix1 and suffix1 are never empty - Balancing does not cross the main data array (i.e. prepending never touches the suffix and appending never touches the prefix). The level is increased/decreased when the affected side plus main data is already full/empty - All arrays are left-aligned and truncated

In addition to the data slices (prefix1, prefix2, ..., dataN, ..., suffix2, suffix1) we store a running count of elements after each prefix for more efficient indexing without having to dereference all prefix arrays.

This class implements immutable maps using a vector/map-based data structure, which preserves insertion order.

Unlike ListMap, VectorMap has amortized effectively constant lookup at the expense of using extra memory and generally lower performance for other operations

This class serves as a wrapper augmenting Strings with all the operations found in indexed sequences.

The difference between this class and StringOps is that calling transformer methods such as filter and map will yield an object of type WrappedString rather than a String.