
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
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/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/