Proposal: add uncons (and unsnoc) to Data.List

[Niklas Haskell]

On Sun, 20 Jul 2014 01:38:12 -0400, Edward Kmett <ekmett at gmail.com> wrote:
> I'd favor unsnoc and uncons over viewL / viewR as the type is a bit
> different having no dedicated view data type, etc.
> 
> uncons seems by far more commonly reinvented name for the concept, being
> used across bytestring, parsec, etc.
> 
> https://www.fpcomplete.com/hoogle?q=uncons&env=ghc-7.4.2-stable-13.09
> 
> While the viewL/viewR's out there all have their heritage in the Data.Seq /
> fingertree usage.
> 
> https://www.fpcomplete.com/hoogle?q=viewl&env=ghc-7.4.2-stable-13.09
> 
> I tend to reserve using viewL / viewR for the dedicated data type variant,
> as because the latter fits in a bit worse with other uses of Maybe but can
> be ever so slightly more efficient due to the dedicated constructor I often
> try to supply both.
> 
> Also a motivation for the uncons nomenclature is it preserves something
> like symmetry between
> `unfoldr uncons` and `foldr (:) []`.
> 
> It is a much easier to sell an uncons/unsnoc than to sell new data types
> and a viewL/viewR to go with them, and it seems to me to be better to
> reserve the latter names for folks who do want to supply such a beast.
> 
> -Edward

For my intuition, it seems like view* functions are generally intended
to be mixed with view patterns for pattern matching on something with
non-exported constructors; whereas uncons for example doesn't really make
sense as a pattern since matching against Just (x, xs) is no different
than matching against x:xs.

Moving forwards in the GHC 7.8 world, I'd almost suggest that everything
that was previously a “viewX” function should now actually be a *pattern
synonym*, like:

pattern (xs :> x) <- (viewRTree -> Just2 xs (Elem x))

(Even better for types where this allows construction as well, but for
Data.Sequence there are many possible ways to represent the same
sequence, so a view pattern is required *somewhere*.)