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

[Joachim Breitner]

Hi,

Am Donnerstag, den 16.04.2020, 14:48 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> 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).  

the variant is described in 6.1.2 of the proposal:
https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst#612qualifieddo-with-operations-that-are-not-in-scope
has a spec (“resolves to any (>>=) that is exported by any module
aliased by the name M, independently of whether it is in scope (i.e.
imported).” and an I think enlightening example (albeit with an odd
duplication of imports).

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

Anything else exported from MyMonad that the user might want to use.

> 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.

Correct.
 
> 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.

And you are sure that the complexity of this is more than that of
“fully settled” types?

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/