<div dir="ltr"><div>I've added some more comments in the GitHub repo.</div><div>TL;DR: I like the current proposal because it's an easy term-to-term translation, instead of more complex approaches which involve type checking. However, I don't know whether we should go through the "module + arguments" route, or the "builder" route.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue., 12 mar. 2020 a las 14:42, Richard Eisenberg (<<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Sorry to say that I do not like this proposal in its current form, as I elaborate on GitHub: <br><div><a href="https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598191928" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598191928</a></div><div><br></div><div>Richard</div><div><br><blockquote type="cite"><div>On Mar 12, 2020, at 8:16 AM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:</div><br><div><div>I support this proposal in the current form. I am especially happy<br>with the idea that the 'M.do' qualifier does not affect the 'return'<br>function. It's just fine to affect implicit constructions exclusively.<br><br>Vitaly<br><br>ср, 11 мар. 2020 г. в 21:37, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>:<br><blockquote type="cite"><br>Dear Committe,<br><br>Proposal:<br><a href="https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst" target="_blank">https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst</a><br><br>Discussion: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/216" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/216</a><br><br><br>Summary:<br><br>last June we looked at a “local do” proposal that would be a more<br>targetted variant of RebindableSyntax, just for “do”. After an initial<br>acceptance recommendation from me we had some good discussion, and<br>eventually sent it back for revision. One problem, among many, was that<br>the story around type inference wasn’t as good as with normal “do”.<br><br>All attempts to give meaning to “do” via a local value (e.g. a record,<br>or type classes etc.) were unsatisfying in one way or another. (Often<br>something about mumble impredicative types mumble.)<br><br>Anyways, Facundo Domínguez joined the author team and the discussion<br>steered towards a less ambitious, but simpler and cleaner proposal:<br>Qualified do. The idea is simply to treat a module qualifier on the do<br>keyword as a qualified on all the implicit :<br><br> M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts })<br><br>and similar for the other monad desugaring rules.<br><br><br>Recommendation:<br><br>This seems simple, convenient and easy to understand, so I recommend<br>accepting the proposal.<br><br><br>Comment:<br><br>There was some discussion if<br><br> M.do { return x } = M.return x<br><br>but it seems that changing the meaning of more than `do` it self may be<br>more confusing than helpful, so the proposal as it stands does _not_<br>propose it (see Alternatives). I wish we had a better story here, and<br>welcome ideas from the committee.<br><br><br>WDYAT?<br><br><br>Cheers,<br>Joachim<br><br><br>--<br>Joachim Breitner<br> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br> <a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br><br><br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></blockquote>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></div></blockquote></div><br></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>