Proposal: add `on` to the Prelude

[Ivan Lazar Miljenovic]

-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190911/7418fe69/attachment.html>