Proposal: add `on` to the Prelude

[Herbert Valerio Riedel]

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 at 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 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
>>
> _______________________________________________
> 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/e24dd838/attachment.html>