<div dir="auto">-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).<div dir="auto"><br></div><div dir="auto">I use `on` a _lot_ and have never once considered doing a custom Prelude or anything like that.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 11 Sep. 2019, 9:00 pm Elliot Cameron, <<a href="mailto:eacameron@gmail.com">eacameron@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Perhaps this question should be answered: What is the guiding principle for Prelude? Why does it exist?<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So, What guides Prelude? Why does Prelude exist?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019, 7:53 AM Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank" rel="noreferrer">hvriedel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello everyone,</div><br><div>To provide another data-point; in my "Prelude module replacement" package</div><div><br></div><div><a href="http://hackage.haskell.org/package/Prelude" rel="noreferrer noreferrer" target="_blank">http://hackage.haskell.org/package/Prelude</a><br></div><div><br></div><div>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:</div><div><br></div><div><a href="http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21" rel="noreferrer noreferrer" target="_blank">http://hackage.haskell.org/package/Prelude-0.1.0.1/docs/Prelude.html#g:21</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 1:32 PM Dmitrii Kovanikov <<a href="mailto:kovanikov@gmail.com" rel="noreferrer noreferrer" target="_blank">kovanikov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 from me<br><div><br></div><div>We export `on` from `relude` by default and didn't have any problems so far:</div><div><br></div><div>* <a href="http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on" rel="noreferrer noreferrer" target="_blank">http://hackage.haskell.org/package/relude-0.5.0/docs/Relude-Function.html#v:on</a></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 1:53 AM David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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?<div dir="auto"><br></div><div dir="auto"><div dir="auto">  on :: (b -> b -> c) -> (a -> b) -> a -> a -> c</div><div dir="auto">  (.*.) `on` f = \x y -> f x .*. f y</div></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>