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

[Alejandro Serrano Mena]

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

Alejandro

El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (<mail at joachim-breitner.de>)
escribió:

> Hmm indeed :-)
>
> Both ways are justifiable. Allow me to explain why using the normal
> operations seem to be a better trade off.
>
> Here is an hypothesis:
>
>   Most people using do-notation throw in some (non-sugar) monad
>   operations from time to time, e.g.:
>
>      do doFoo
>         z <- bar x >>= baz >>= quux
>         return (f z)
>
> This will not change if they use qualifed monads, so we better allow
> them to write
>
>      M.do doFoo
>         z <- bar x M.>>= baz M.>>= quux
>         M.return (f z)
>
> So I expect that any module M that is set up to be used qualified will
> want to export (>>=) and (>>) and return anyways.
>
> This observation does not require us to use these in the desugaring.
> But since they are there, it seems natural to use them.
>
> If we don’t, then
>  * some modules export qualifiedDoBind and (>>=)
>    which is redundant (and makes one wonder if they are the same)
>  * a few modules might not export (>>=) (only qualifiedDoBind)
>    for whatever reason
>    This adds cognitive load on the user, who now has to check and
>    remember for which M.do they also can use  M.>>=
>
> I acknowledge the downside that such a module M may be less easy to
> recognize as “supports qualified do” just given the list of exports.
> (Some may call that a feature, e.g. Prelude.do would just work…)
> I hope that a good haddock module header can address that, maybe by
> having a section “Used of the Linear monad with QualifiedDo” or such.
>
>
> Cheers,
> Joachim
>
> Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones:
> > Hmm.  I can see the attraction of using other less widely used names like
> >       M.qualifiedDoBind
> >       M.qualifiedDoFail
> >       M.qualifedDoMFix
> >
> > Then searching for `qualifiedDo` would find the things that are used
> > for, well qualified do.  Remember, by using the module-prefix form we
> > are making it harder to group together the operations that make up
> > the things used by qualified do -- (>>), (>>=) etc are among the most
> > widely used lexemes in Haskell.
> >
> > I'm not immovable on this, but I think there's a case for using long,
> explicit names.  If you end up saying
> >       qualifiedDoBind = (>>=)
> > that would be a very good clue that you intend this operation to be used
> by Qualified Do.
> >
> > Simon
> >
> > > -----Original Message-----
> > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org>
> > > On Behalf Of Joachim Breitner
> > > Sent: 08 May 2020 23:02
> > > To: ghc-steering-committee at haskell.org
> > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again,
> > > recommendation: accept the alternative
> > >
> > > Hi,
> > >
> > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner:
> > > > Hi,
> > > >
> > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud:
> > > > > There is one question to solve: should we use the standard names
> > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can
> > > > > be used directly). Or some dedicated names `desugaringBind`, … ? To
> > > > > avoid name clashes.
> > > >
> > > > given that the recommended idiom is to only use this with a qualified
> > > > module name, I think using the normal, well-known names is
> reasonable.
> > >
> > > do we have more opinions on this? If not we can go with the author’s
> > > proposal, which is to use the standard names. It’s natural that when I
> can
> > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can
> > > expect M.>> to be there for every module M that they would use to
> qualify
> > > `do`.
> > >
> > >
> > > 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
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200509/0aa3857e/attachment.html>