Stepping to one side of the discussion could I just  point out that, notation is not just about the form of the final program. One of the claimed strengths and appeals of FP is the opportunity for program transformation via a useful

repertoire of algebraic law, cf the work on Squiggol, and the numerous functional pearls by folk including Richard Bird et.al..

This work befits from having concisely-expressed rules that open the road to manipulation - long-winded

identifiers suitable for large libraries are not necessarily ideal for algebraic

manipulation. Ye you could treat the two as separate entities, But a pleasant feature of Haskell is the ability to work with the notation both for developmemt and final program.

Going back to the original proposal, I'm not bothered, I would probably just ignore a singleton library.  However I'm -1 on philosophical grounds.

I'm used to teaching FP to undergrads and half the battle is encouraging people to think functionally, to

make use of the underlying mathematics and computational model rather than transliterate <insert your favourite 'bete noir'> into Haskell. That means thinking of building programs from

functional fragments combined by suitable glue, and appreciating that data constructors can be used

as functions Yes it takes beginner's time to recognise some of the patterns,  and (:[] is just one such example(when the light dawns, 

the transformation is rewarding. I've lost count of the number of jaws I've had to pick off the floor :)

So I don't want to make a mountain out of a molehill. If it will really  improve programmers' 

lives then okay, So far I' not convinced, and but in fretting over final code can we please not   lose sight of the 'bigger picture' and challenges..