Proposal: add `on` to the Prelude

[Dmitrii Kovanikov]

+1 from me

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

*
http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on

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
function.

On Wed, Sep 11, 2019 at 1:53 AM David Feuer <david.feuer at gmail.com> 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 haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190911/bcba6e8d/attachment.html>