<div dir="ltr"><div><div>I really like using the standard names, but greppability is desirable too. So perhaps a reasonable convention would be <br></div></div><div><br></div><div>module MyLib.QualifiedDo ( (>>=), (>>), fail ) where { ... }</div><div><br></div><div>then</div><div><br></div><div>import MyLib.QualifiedDo as MyLib</div><div><br></div><div>...   MyLib.do { ... }</div><div><br></div><div>you could easily grep for modules named `.QualifiedDo`. It would be just a convention, of course.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 May 2020 at 09:12, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<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 lang="EN-GB">
<div class="gmail-m_7810232387456730000WordSection1">
<p class="MsoNormal"><span>I agree that having longer names would mean that you may have to say<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>module M( (>>=), (>>), fail<u></u><u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>             , qualifiedBind, qualifiedThen, qualifiedFail ) where<u></u><u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span><u></u> <u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>qualifiedBind = (>>=)<u></u><u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>qualifiedThen = (>>)<u></u><u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>qualifiedFail = fail<u></u><u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span><u></u> <u></u></span></p>
<p class="gmail-m_7810232387456730000Code"><span>…defns of (>>=) etc…<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>but you could regard those extra lines as a feature, rather than a bug. They say “I’m planning to use these operators for M.do”.   I like that.  And I like being able to grep for things in a large
 codebase.  (Grepping for (>>=) is useless.)<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>But I can see that judgements might vary.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>>
<b>On Behalf Of </b>Alejandro Serrano Mena<br>
<b>Sent:</b> 09 May 2020 20:13<br>
<b>To:</b> Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
<b>Cc:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<b>Subject:</b> Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I am with Joachim in the use of "normal" names as opposed to special "qualifiedX". At least in my case, I tend to use >>= and >> here and there in my monadic code, so having them exported from the same module would be desirable. In fact, I would expect those
 modules to also export something akin to <$> and <*>.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Alejandro<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (<<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>) escribió:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hmm indeed :-)<br>
<br>
Both ways are justifiable. Allow me to explain why using the normal<br>
operations seem to be a better trade off.<br>
<br>
Here is an hypothesis:<br>
<br>
  Most people using do-notation throw in some (non-sugar) monad <br>
  operations from time to time, e.g.:<br>
<br>
     do doFoo<br>
        z <- bar x >>= baz >>= quux<br>
        return (f z)<br>
<br>
This will not change if they use qualifed monads, so we better allow<br>
them to write <br>
<br>
     M.do doFoo<br>
        z <- bar x M.>>= baz M.>>= quux<br>
        M.return (f z)<br>
<br>
So I expect that any module M that is set up to be used qualified will<br>
want to export (>>=) and (>>) and return anyways.<br>
<br>
This observation does not require us to use these in the desugaring.<br>
But since they are there, it seems natural to use them.<br>
<br>
If we don’t, then<br>
 * some modules export qualifiedDoBind and (>>=)<br>
   which is redundant (and makes one wonder if they are the same)<br>
 * a few modules might not export (>>=) (only qualifiedDoBind)<br>
   for whatever reason<br>
   This adds cognitive load on the user, who now has to check and<br>
   remember for which M.do they also can use  M.>>=<br>
<br>
I acknowledge the downside that such a module M may be less easy to<br>
recognize as “supports qualified do” just given the list of exports.<br>
(Some may call that a feature, e.g. Prelude.do would just work…)<br>
I hope that a good haddock module header can address that, maybe by<br>
having a section “Used of the Linear monad with QualifiedDo” or such.<br>
<br>
<br>
Cheers,<br>
Joachim<br>
<br>
Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones:<br>
> Hmm.  I can see the attraction of using other less widely used names like<br>
>       M.qualifiedDoBind<br>
>       M.qualifiedDoFail<br>
>       M.qualifedDoMFix<br>
> <br>
> Then searching for `qualifiedDo` would find the things that are used<br>
> for, well qualified do.  Remember, by using the module-prefix form we<br>
> are making it harder to group together the operations that make up<br>
> the things used by qualified do -- (>>), (>>=) etc are among the most<br>
> widely used lexemes in Haskell.<br>
> <br>
> I'm not immovable on this, but I think there's a case for using long, explicit names.  If you end up saying<br>
>       qualifiedDoBind = (>>=)<br>
> that would be a very good clue that you intend this operation to be used by Qualified Do.<br>
> <br>
> Simon<br>
> <br>
> > -----Original Message-----<br>
> > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><br>
> > On Behalf Of Joachim Breitner<br>
> > Sent: 08 May 2020 23:02<br>
> > To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > Subject: Re: [ghc-steering-committee] #216: Qualified Do again,<br>
> > recommendation: accept the alternative<br>
> > <br>
> > Hi,<br>
> > <br>
> > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner:<br>
> > > Hi,<br>
> > > <br>
> > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud:<br>
> > > > There is one question to solve: should we use the standard names<br>
> > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can<br>
> > > > be used directly). Or some dedicated names `desugaringBind`, … ? To<br>
> > > > avoid name clashes.<br>
> > > <br>
> > > given that the recommended idiom is to only use this with a qualified<br>
> > > module name, I think using the normal, well-known names is reasonable.<br>
> > <br>
> > do we have more opinions on this? If not we can go with the author’s<br>
> > proposal, which is to use the standard names. It’s natural that when I can<br>
> > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can<br>
> > expect M.>> to be there for every module M that they would use to qualify<br>
> > `do`.<br>
> > <br>
> > <br>
> > Cheers,<br>
> > Joachim<br>
> > --<br>
> > Joachim Breitner<br>
> >   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> >   <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce9fed952b2ac4d6d94e808d7f44d0197%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637246483894365128&sdata=aVA%2BFFcNViULzX%2B1awe8oCkE74avIhz50jyOup0tYAs%3D&reserved=0" 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://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%7Ce9fed952b2ac4d6d94e808d7f44d0197%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637246483894375125&sdata=AAJ3WkF%2BjQWpQcHeIA3kwF2hU4kjsqKC9kKffqf7iyo%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce9fed952b2ac4d6d94e808d7f44d0197%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637246483894375125&sdata=0VFHs12K4Co7BCqK8Byme%2BIaCZBSLJuc%2BIrjgm57LVA%3D&reserved=0" 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://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%7Ce9fed952b2ac4d6d94e808d7f44d0197%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637246483894385121&sdata=t3edpQsri4nEzJyY92aOQrDY%2F7yJ2EVgavpc%2FKF1yws%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</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>