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

Simon Peyton Jones simonpj at microsoft.com
Thu Apr 16 14:48:53 UTC 2020 

I’m sorry I’m slow, but I just don’t yet understand what is being proposed.

Joachim launched the discussion here<https://mail.haskell.org/pipermail/ghc-steering-committee/2020-April/001533.html>.   I believe that he is advocating section 6.1 in the proposal.  Moreover he has some variant of it in mind.  I asked some questions<https://mail.haskell.org/pipermail/ghc-steering-committee/2020-April/001545.html> about the variant that may or may not have been answered.

It would be really helpful to have a single source of truth.  Perhaps someone (Joachim or anyone else) can write a Google doc that describes, as precisely as possible, the proposal that he is advocating.  Or get the proposal authors to do so.   Just saying “a variant where the value does not need to be in scope” does not count as a specification (to me).

Iavor’s writeup below is helpful, but I fall over immediately.  First, I believe that his (1-4) things are not *design* alternatives; they are all things the programmer can write, all under Section 6.1 of the proposal (unmodified).  Is that right.

Then.
    1. import MyMonad as M
       (+) other operations do not need to be qualified
       (-) unqualified `>>=` may be ambiguous

What are “other operations”?
Why might “>>=” be ambiguous?  I think the answer is: because MyMonad must export it (to use in M.do), but it may already be in scope from the Prelude.

I’m strongly inclined against inventing new complexity in the module system, unless it is absolutely unavoidable. More to specify, more to explain, more to understand, more to implement.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 14 April 2020 17:15
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative

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<mailto: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<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C66be21fcd8d74e052a3608d7e08f1857%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637224777509071750&sdata=TWMDeXho9obNmy%2FW0DJQn5Lq5PmQcWXh4NTRoLt2bvo%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C66be21fcd8d74e052a3608d7e08f1857%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637224777509081745&sdata=ytwWAGYW8iNbV2MNYf7hiUWvwOHat1noPOu0swTYbgw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200416/df58f6e8/attachment-0001.html>

More information about the ghc-steering-committee mailing list