Proposal #3271: new methods for Data.Sequence
Ross Paterson
ross at soi.city.ac.uk
Wed Aug 19 11:20:23 EDT 2009
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).
More information about the Libraries
mailing list