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.
While the viewL/viewR's out there all have their heritage in the Data.Seq / fingertree usage.
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.