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 <mail@joachim-breitner.de> wrote:
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