<div dir="ltr">Hello,<div><br></div><div>as the Github discussion is pretty long, I thought it might be useful to have a summary of the observations to the issue being discussed, namely how to resolve the names in `M.do`.</div><div><br></div><div>Without the special syntax suggested by Joachim, a programmer has the following options to make `M.do` work, and I've marked some (potential) pros/cons:</div><div><font face="monospace"><br></font></div><div><div><font face="monospace"> 1. import MyMonad as M</font></div><div><font face="monospace"> (+) other operations do not need to be qualified</font></div></div><div><font face="monospace"> (-) unqualified `>>=` may be ambiguous</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"> 2. import qualified MyMonad as M</font></div><div><font face="monospace"> (-) other operations need to be qualified</font></div><div><font face="monospace"> (+) unqualified `>>=` is not ambiguous</font></div><div><br></div><div><font face="monospace"> 3. import qualified MyMonas as M</font></div><div><font face="monospace"> import MyMonad (other,operations)</font></div><div><font face="monospace"> (+) other operations do not need to be qualified</font></div><div><font face="monospace"> (+) unqualifed `>>=` is not ambiguous</font></div><div><font face="monospace"> (-) requires two imports</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Joachim's proposal aims to improve on (3) by allowing programmers to write:</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="monospace"> 4. import MyMonad as M (other,operations)</font></div><div><font face="monospace"> (+) other operations do not need to be qualified</font></div><div><font face="monospace"> (+) unqualified `>>=` are not ambiguous</font></div><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">The idea is that the renamer would compute the original name to use in the desugaring by seeing if `>>=` is exported by one of the modules imported with alias `M`. GHC certainly has the required information, and I doubt this would be hard to implement.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">As I said in my previous e-mail, I don't have a strong feeling about the choice we make, but I wanted to make sure that we are all discussing the same thing.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">-Iavor</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="monospace"><br></font></div><div><br></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"> </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 14, 2020 at 8:28 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">Hi,<br>
<br>
Am Dienstag, den 14.04.2020, 11:36 +0000 schrieb Simon Peyton Jones via<br>
ghc-steering-committee:<br>
> Qualified names like M.foo, which always mean “the foo imported from<br>
> module M – albeit with import-qualified you can change the local<br>
> name”<br>
<br>
but it’s not that simple: What if I write<br>
<br>
import qualified M1 as M<br>
import qualified M2 as M<br>
<br>
and then use M.foo?<br>
Well, it resolves the foo imported from M1, if M1 exports it.<br>
Or from M2, if M2 exports it.<br>
But what if both export it? Then we get an “ambiguity error”…<br>
Unless M1.foo and M2.foo, via re-exports, point to the same original<br>
name.<br>
<br>
What is proposed for M.(>>) here is the same logic, with the addition<br>
that it doesn’t matter whether you used “hiding ((>>))” somewhere in<br>
these imports, or imported (), to keep the nice existing rule<br>
“You only import what you explicitly mention”<br>
<br>
In terms of implementation I don’t think the burden is high; GHC<br>
already has that logic for the “M.foo is not in scope, did you want to<br>
add foo to the export list in line x” error message.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>