Proposal: add `on` to the Prelude

Dmitrii Kovanikov kovanikov at
Wed Sep 11 11:32:05 UTC 2019

+1 from me

We export `on` from `relude` by default and didn't have any problems so far:


I believe that this proposal hits the same wall like all other proposals
regarding changes to the standard library — it's not clear, what are
Prelude goals. Should it be minimal and provide only fundamental things, or
should it enforce commonly used idioms? I think that the `on` function from
this proposal is the most widely used version of any other function with
the same name. When I see `on` in the code, I first expect the version from
`base`, not from some external library with a different type. Implementing
your own `on` in your library and forcing users to use it makes code hard
to read and reason about. Especially when people are using implicit imports
— good luck figuring out which one `on` is used! I believe that if `on` was
already imported by `Prelude`, fewer people would introduce identifiers
with this name. Which means that exporting `on` from `Prelude` is an
excellent thing to do if `Prelude` wants to force idiomatic usage of this

On Wed, Sep 11, 2019 at 1:53 AM David Feuer <david.feuer at> wrote:

> Every time I reach for Data.Function.on, I feel like a total dolt for
> having to import a module to get a function whose implementation is barely
> longer than the import. And it's a really good function too! Can we please
> add it to the Prelude?
>   on :: (b -> b -> c) -> (a -> b) -> a -> a -> c
>   (.*.) `on` f = \x y -> f x .*. f y
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list