<div><div dir="auto">Qualified exports seem very unproblematic to me.  And they should be easy to implement. It’s just an extra flag on each exported entity that tells compiler if the unqualified name should be entered into the symbol table or not. </div></div><div dir="auto"><br></div><div dir="auto">  — Lennart</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 11:04 Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@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>hey Levent,</div><div>I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)<br></div><div><br></div><div>its definitely an interesting idea, and i certainly dont have clarity on what the implications would be</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <<a href="mailto:erkokl@gmail.com" target="_blank">erkokl@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">I think Carter outlined really good reasons for not including `e<span class="m_6034955794139483675gmail-m_-2184698978720909592gmail-gr_ m_6034955794139483675gmail-m_-2184698978720909592gmail-gr_50 m_6034955794139483675gmail-m_-2184698978720909592gmail-gr-alert m_6034955794139483675gmail-m_-2184698978720909592gmail-gr_gramm m_6034955794139483675gmail-m_-2184698978720909592gmail-gr_inline_cards m_6034955794139483675gmail-m_-2184698978720909592gmail-gr_run_anim m_6034955794139483675gmail-m_-2184698978720909592gmail-Punctuation m_6034955794139483675gmail-m_-2184698978720909592gmail-multiReplace" id="m_6034955794139483675gmail-m_-2184698978720909592gmail-50" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat">`;</span> but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.<div><br></div><div>I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)</div><div><br></div><div>I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 10:32 AM chessai . <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@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">asymmetry in presence, not use.<div dir="auto"><br></div><div dir="auto">When I was first learning Haskell, the absence of e along with the presence of pi in Floating confused me. It is not a disservice to users to note this asymmetry in documentation and why it is not there.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@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">i dont see it as an assymetry, theres a lot of very simple volume / area / probability /geometry calculations  where pi comes up, <div>i dont know any for e that aren't just exp. can you share some?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 10:50 PM chessai . <<a href="mailto:chessai1996@gmail.com" rel="noreferrer" target="_blank">chessai1996@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">Yeah, I think it probably shouldn't be added to the typeclass then.<div dir="auto"><br></div><div dir="auto">The asymmetry should probably be mentioned in the report though.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@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">either way, we're not gonna add e :) </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <<a href="mailto:gale@sefer.org" rel="noreferrer noreferrer" target="_blank">gale@sefer.org</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">Lennart's question "Is it really worth it?" is the most important one.<br>
And no, probably it isn't.<br>
<br>
But Chessai is correct that this is a weird asymmetry in the Floating<br>
class. My own experience is that I user neither e nor pi very much,<br>
but neither one more than the other.<br>
<br>
Branch cuts of inverse trig functions are not relevant. The report<br>
doesn't explicitly state this, but it's clear that these functions are<br>
expected to return the standard ranges of values as in other<br>
programming languages. You can be quite certain that acos (-1) is pi<br>
in Haskell. And in fact, we have (at least on my computer)<br>
<br>
Prelude> acos (-1) == pi<br>
True<br>
<br>
So there isn't any more or less reason to have e than pi as a separate<br>
class member.<br>
<br>
On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson<br>
<<a href="mailto:lennart@augustsson.net" rel="noreferrer noreferrer" target="_blank">lennart@augustsson.net</a>> wrote:<br>
><br>
> Is it really worth it?  How frequent are uses of e, except used like exp?  On the other hand, pi has more frequent standalone use cases.<br>
> Also, e has a simple definition (exp 1), whereas pi is somewhat more involved.<br>
><br>
> The logp1 and expm1 functions where added for good numerical reasons.  The same would not be true for e.<br>
><br>
> On Sat, Feb 16, 2019 at 21:14 chessai . <<a href="mailto:chessai1996@gmail.com" rel="noreferrer noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br>
>><br>
>> We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p.<br>
>><br>
>> Why not provide an 'e' constant?<br>
>><br>
>> A default implementation could just be 'exp 1'.<br>
>> _______________________________________________<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>
><br>
> _______________________________________________<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>
_______________________________________________<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>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>