Proposal #3271: new methods for Data.Sequence

[Ross Paterson]

Two more things:

I think that tails and inits may be more complex than necessary.  When I
see partial pattern matches like in zipDigit/zipNode, I worry that the
hidden invariants are both extra complexity for a human reader and a
missed opportunity for the compiler.  I think you're doing it because
you want the two traversals to go in opposite directions, so that you
don't need to start with the total size of the prefix or suffix, but
it turns out that you're computing these anyway.  So you might as well
combine the pairs of traversals in each case.

The names of the sequential search functions:

       takeWhile       :: (a -> Bool) -> Seq a -> Seq a
       takeWhileEnd    :: (a -> Bool) -> Seq a -> Seq a
       dropWhile       :: (a -> Bool) -> Seq a -> Seq a
       dropWhileEnd    :: (a -> Bool) -> Seq a -> Seq a
       span            :: (a -> Bool) -> Seq a -> (Seq a, Seq a)
       spanEnd         :: (a -> Bool) -> Seq a -> (Seq a, Seq a)
       break           :: (a -> Bool) -> Seq a -> (Seq a, Seq a)
       breakEnd        :: (a -> Bool) -> Seq a -> (Seq a, Seq a)
       elemIndex       :: Eq a => a -> Seq a -> Maybe Int
       elemIndices     :: Eq a => a -> Seq a -> [Int]
       elemLastIndex   :: Eq a => a -> Seq a -> Maybe Ind
       elemIndicesDesc :: Eq a => a -> Seq a -> [Int]
       findIndex       :: (a -> Bool) -> Seq a -> Maybe Int
       findIndices     :: (a -> Bool) -> Seq a -> [Int]
       findLastIndex   :: (a -> Bool) -> Seq a -> Maybe Int
       findIndicesDesc :: (a -> Bool) -> Seq a -> [Int]

conflict with the symmetrical view of sequences elsewhere in the
interface.  Sequences are viewed as having left and right ends, not front
and back or first and last.  (Of course the existing functions take and
drop have similar issues, but at least they didn't involve new names.)
So I'd prefer L and R variants of each (perhaps with spanl/spanr and
breakl/breakr for consistency with other similar names).