是否有更严格的Data.Sequence？

Question

The following example shows a problem that we have with Data.Sequence :

{-# LANGUAGE BangPatterns #-}
module Main where

import qualified Data.Sequence as S
import Data.Sequence ((|>), ViewL(..))
import Data.List (foldl')
import GHC.AssertNF

update !init !x = init |> x

main =
   do let !seq = foldl' update S.empty [1..10]
      assertNF seq

It prints

Parameter not in normal form: 1 thunks found:
Deep (One (S# 1)) (_thunk (Deep (One ...) (_thunk ... ... ... ...) (Three ... ... ...) 93) (S# 95) (S# 96) (S# 97)) (Three (S# 98) (S# 99) (S# 100)) 100

However, the documentation of Data.Sequence claims that all the operations are strict, so why isn't the tree fully evaluated after the insert? Is it needed to guarantee some of the amoritized complexity bounds?

We don't like laziness here very much, so I wonder if there is a stricter |> or a similar data structure that supports appending to the back and enumeration from the front, possibly a more efficient one?

Answer 1

Data.Sequence is a element strict, digit strict data structure with a lazy spine.

data FingerTree a
    = Empty
    | Single a
    | Deep {-# UNPACK #-} !Int !(Digit a) (FingerTree (Node a)) !(Digit a)

This means inserted values will be stored evaluated, but the spine of the structure will only be evaluated on query. That's often what you want -- smaller data structures.

If you want to force a strict spine on it, you will incur a heavier insertion cost, but you might gain somewhere else.

Try modifying the fingertrees package to be spine strict and see if it is actually faster -- I will be interested to know the result.

---

As an aside: "We don't like laziness here very much," isn't a good reason to avoid spine-lazy data structures. If [a] was spine strict, it would be a terrible data type. The same may be true for Data.Sequence. You should quantify why spine-strictness is the wrong semantics for your use case.

Answer 2

Good performance of finger trees depends on laziness. To quote from Hinze, Ralf; Paterson, Ross (2006), "Finger Trees: A Simple General-purpose Data Structure" :

... Although the structure makes essential use of laziness, it is also suitable for strict languages that provide a lazy evaluation primitive.

and when analyzing its properties:

...Consequently, in a sequence of operations, the average cost is constant.

The same bounds hold in a persistent setting if subtrees are suspended using lazy evaluation. This ensures that transformations deep in the spine do not take place until a subsequent operation needs to go down that far. Because of the above properties of safe and dangerous digits, by that time enough cheap shallow operations will have been performed to pay for this expensive evaluation.

So if you change the implementation from lazy to strict, you could possibly lose the good time complexity bounds (depending on what operations you use and in what order).