[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative
Simon Peyton Jones
simonpj at microsoft.com
Mon May 11 08:12:22 UTC 2020
I agree that having longer names would mean that you may have to say
module M( (>>=), (>>), fail
, qualifiedBind, qualifiedThen, qualifiedFail ) where
qualifiedBind = (>>=)
qualifiedThen = (>>)
qualifiedFail = fail
…defns of (>>=) etc…
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.)
But I can see that judgements might vary.
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 09 May 2020 20:13
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative
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<mailto: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<mailto: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<mailto: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<mailto:mail at joachim-breitner.de>
> > http://www.joachim-breitner.de/<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>
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<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>
--
Joachim Breitner
mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
http://www.joachim-breitner.de/<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>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200511/97e94572/attachment-0001.html>
More information about the ghc-steering-committee
mailing list