[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative

[Iavor Diatchki]

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 at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200414/c2379f06/attachment.html>