Hello everyone,

To provide another data-point; in my "Prelude module replacement" package

http://hackage.haskell.org/package/Prelude

which encodes a common standard vocabulary from `base` I've observed in my own projects over the years where I often keep a "local prelude" module for the purpose of establishing a project-specific common vocabulary. Under these constraints,  `on` as well as `&` happens to be such a common vocabulary which I expect to have in my default scope, and thus is reexported from the "Prelude" module:

http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21

But then again, since it's so easy to implement your own opinionated "Prelude" replacement (either project-local or as a package on Hackage), and subjective tastes differ greatly as the recent controversial "singleton" proposal showed, and even though reexporting `on` from Prelude has an objective merit in contrast, and I can definitely sympathise with *this* proposal,  I'm not sure if we really need to modify `base` to achieve the stated goal of having a more convenient function in scope.

But to be clear; at this point, I'm neither for nor against the proposal to reexport names from Data.Function from the `base` Prelude.

On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov <kovanikov@gmail.com> wrote:
+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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries