Hello,
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`.
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:
1. import MyMonad as M
(+) other operations do not need to be qualified
(-) unqualified `>>=` may be ambiguous
2. import qualified MyMonad as M
(-) other operations need to be qualified
(+) unqualified `>>=` is not ambiguous
3. import qualified MyMonas as M
import MyMonad (other,operations)
(+) other operations do not need to be qualified
(+) unqualifed `>>=` is not ambiguous
(-) requires two imports
Joachim's proposal aims to improve on (3) by allowing programmers to write:
4. import MyMonad as M (other,operations)
(+) other operations do not need to be qualified
(+) unqualified `>>=` are not ambiguous
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.
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.
-Iavor
On Tue, Apr 14, 2020 at 8:28 AM Joachim Breitner
Hi,
Am Dienstag, den 14.04.2020, 11:36 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
Qualified names like M.foo, which always mean “the foo imported from module M – albeit with import-qualified you can change the local name”
but it’s not that simple: What if I write
import qualified M1 as M import qualified M2 as M
and then use M.foo? Well, it resolves the foo imported from M1, if M1 exports it. Or from M2, if M2 exports it. But what if both export it? Then we get an “ambiguity error”… Unless M1.foo and M2.foo, via re-exports, point to the same original name.
What is proposed for M.(>>) here is the same logic, with the addition that it doesn’t matter whether you used “hiding ((>>))” somewhere in these imports, or imported (), to keep the nice existing rule “You only import what you explicitly mention”
In terms of implementation I don’t think the burden is high; GHC already has that logic for the “M.foo is not in scope, did you want to add foo to the export list in line x” error message.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee