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

[Vitaly Bragilevsky]

I support this proposal in the current form. I am especially happy
with the idea that the 'M.do' qualifier does not affect the 'return'
function. It's just fine to affect implicit constructions exclusively.

Vitaly

ср, 11 мар. 2020 г. в 21:37, Joachim Breitner <mail at joachim-breitner.de>:
>
> Dear Committe,
>
> Proposal:
> https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst
>
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216
>
>
> Summary:
>
> last June we looked at a “local do” proposal that would be a more
> targetted variant of RebindableSyntax, just for “do”. After an initial
> acceptance recommendation from me we had some good discussion, and
> eventually sent it back for revision. One problem, among many, was that
> the story around type inference wasn’t as good as with normal “do”.
>
> All attempts to give meaning to “do” via a local value (e.g. a record,
> or type classes etc.) were unsatisfying in one way or another. (Often
> something about mumble impredicative types mumble.)
>
> Anyways, Facundo Domínguez joined the author team and the discussion
> steered towards a less ambitious, but simpler and cleaner proposal:
> Qualified do. The idea is simply to treat a module qualifier on the do
> keyword as a qualified on all the implicit :
>
>   M.do { x <- u; stmts }  =  (M.>>=) u (\x -> M.do { stmts })
>
> and similar for the other monad desugaring rules.
>
>
> Recommendation:
>
> This seems simple, convenient and easy to understand, so I recommend
> accepting the proposal.
>
>
> Comment:
>
> There was some discussion if
>
>   M.do { return x } = M.return x
>
> but it seems that changing the meaning of more than `do` it self may be
> more confusing than helpful, so the proposal as it stands does _not_
> propose it (see Alternatives). I wish we had a better story here, and
> welcome ideas from the committee.
>
>
> WDYAT?
>
>
> 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