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

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