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

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 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 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@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 09 May 2020 20:13 *To:* Joachim Breitner *Cc:* ghc-steering-committee@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@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

...

Hmm. I can see the attraction of using other less widely used names

Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: 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@haskell.org>

...

...

On Behalf Of Joachim Breitner Sent: 08 May 2020 23:02 To: ghc-steering-committee@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@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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee