On Wed, Apr 7, 2010 at 11:28 AM, Johan Tibell
I added a reply to the ticket just before you sent this email. :)
Johan, thanks for your reply. Let me quote it:
I'm not in favor of this proposal. Naming trivial compositions puts a complexity tax on all users of the library...
Note that I'm proposing to export <$$> from Data.Functor not from the Prelude. So the complexity tax is localized for users of that module only.
...and we end up with 2*n operators instead of n operators and one flip function. It's trivial to define the function locally or in a helper module.
In a way I already see modules like Control.Monad, Control.Applicative, Control.Arrow, Data.Functor, etc. has "helper" modules defining trivial compositions of the primitive methods.
To elaborate: At work some of our core APIs have gotten dramatically more complex due to their maintainers allowing people, in interest to keep their own code cleaner, to add small helper functions to those APIs. This is now recognized as bad practice and discouraged with a call to "not fear the semicolon"! (We use mostly imperative languages at work.)
In Haskell this will probably be called: "not fear the dot!" :-) Of course that problem can also be solved by exporting these trivial compositions from a different module from which the primitives are exported. However some of these trivial compositions are so useful that users tend to always include both the primitive module and the helper module, thereby defeating the purpose of the split modules a bit. I'm more in favor of exporting both the primitive and the trivial compositions from the same module provided there's good documentation with clear sectioning available. regards, Bas