Add flipped fmap
Bas van Dijk
v.dijk.bas at gmail.com
Wed Apr 7 08:11:29 EDT 2010
On Wed, Apr 7, 2010 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> 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
> ...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
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.
More information about the Libraries