Proposal: add `on` to the Prelude

[Oliver Charles]

-1, for the same reasons as Ivan.

I would prefer *everything* to have an explicit import "binding site",
and I'd also rather that not be a huge single line from one module
(though of course, I can break the import up other multiple lines).

On Wed, Sep 11, 2019 at 3:11 PM Ivan Lazar Miljenovic
<ivan.miljenovic at gmail.com> wrote:
>
> -1 from me; I have no problem with long import lists as I'd prefer to know _where_ a function comes from than keeping track of "what's in Prelude this month?" (looking at you random Monoid, Semigroup, etc. additions to Prelude).
>
> I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that.
>
> On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, <eacameron at gmail.com> wrote:
>>
>> Perhaps this question should be answered: What is the guiding principle for Prelude? Why does it exist?
>>
>> This is probably the most contentious module in all of Haskell's ecosystem. Everyone wants to vie for their definition of "idiomatic" and getting something into Prelude is how you "win". But we all already have things in Prelude we don't like... Like head... How did that get in there? I'm sure many of us would love to go back and remove it. But once something is in Prelude it's "idiomatic" so becomes extremely hard to remove.
>>
>> So, What guides Prelude? Why does Prelude exist?
>>
>> If there's an answer to that in the report or something, I sense it would make these discussions so much simpler. If there is no answer then there is no metric by which to judge any comment in this thread.
>>
>>
>> On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries