On Sun, 20 Jul 2014 01:38:12 -0400, Edward Kmett
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*.)