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

I’m sorry I’m slow, but I just don’t yet understand what is being proposed. Joachim launched the discussion herehttps://mail.haskell.org/pipermail/ghc-steering-committee/2020-April/001533..... I believe that he is advocating section 6.1 in the proposal. Moreover he has some variant of it in mind. I asked some questionshttps://mail.haskell.org/pipermail/ghc-steering-committee/2020-April/001545.... 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 On Behalf Of Iavor Diatchki Sent: 14 April 2020 17:15 To: Joachim Breitner Cc: ghc-steering-committee 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 mailto: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.demailto:mail@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@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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