<div dir="ltr"><div>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 <*>.</div><div><br></div><div>Alejandro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (<<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">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="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" 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="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>