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

Tue May 12 22:06:51 UTC 2020

I don't have an opinion on what the operations should be called, and am
happy to leave it to others to decide.
-Iavor

On Tue, May 12, 2020 at 1:32 PM Simon Marlow <marlowsd at gmail.com> wrote:

> I really like using the standard names, but greppability is desirable too.
> So perhaps a reasonable convention would be
>
> module MyLib.QualifiedDo ( (>>=), (>>), fail ) where { ... }
>
> then
>
> import MyLib.QualifiedDo as MyLib
>
> ...   MyLib.do { ... }
>
> you could easily grep for modules named `.QualifiedDo`. It would be just a
> convention, of course.
>
> Cheers
> Simon
>
>
> On Mon, 11 May 2020 at 09:12, Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> 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>) 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/
>> <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
>> > >
>> 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
>>   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
>> 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>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20200512/1a6af5cd/attachment-0001.html>