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

[Spiwack, Arnaud]

I can certainly live with the module-based version.

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.

On Wed, May 6, 2020 at 3:51 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> glad that are converging! Arnaud, can you live with this too?
>
> If you do, then I’ll announce that we have accepted the proposal in the
> variant “6.1”, i.e.
>
> https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst#do-with-a-module-name
> without any strange special handling of scoping rules (i.e. not 6.1.2).
>
> I still slightly prefer them, but they were contentious, and should we
> later learn that users really want them, we can add them in a backward-
> compatible way, so no need to debate that contentious point now.
>
>
> Cheers,
> Joachim
>
> Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I have finally devoted some time to thinking about this properly.
> >
> > TL;DR: I have made my peace with the module-qualified version.
> >
> > I agree with Arnaud’s points – I have always wanted to group the
> operations of the builder together – but the module-qualified version is so
> easy to explain, understand, and implement, that I think it wins.
> >
> > For me the other alternative would be to do nothing, and wait for a
> better idea to come along.  E.g. as the proposal points out, we may have
> other reasons to want fully settled types.   But it is really, really
> attractive to overload the do-notation for other strange monads.
> >
> > My only real anxiety is that we really will think of a better plan in a
> few years, and then be stuck with back-compat stuff of code that uses
> M.do.   But maybe we should jump that bridge if we come to it.
> >
> > Simon
> >
> > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> On Behalf Of Spiwack, Arnaud
> > Sent: 05 May 2020 09:32
> > To: Joachim Breitner <mail at joachim-breitner.de>
> > Cc: ]Ghc steering committee <ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] #216: Qualified Do again,
> recommendation: accept the alternative
> >
> >
> > > 2. Error messages come up too.
> > >
> > > […]
> > >
> > >    So you’d either get maybe
> > >
> > >       You have qualified the do block in … with Foo.builder, but
> > >       Foo.builder is of type Foo.Builder and the record Builder
> > >       does not have a field named (>>).
> > >
> > >    vs.
> > >
> > >       You have qualified the do block in … with Foo, but the module
> > >       Foo does not export a value named (>>).
> >
> >
> > I want to stress that these, if they read as just as good English
> sentences, don't mean the same thing. The former says: you are using a
> construction, in your do notation, that your builder doesn't support. The
> latter says: you haven't imported the module which export this
> construction, which may or may not exist.
> >
> > Let me make up an example. It is not the case in `base`, but let's
> imagine that `MonadFail` ins in a different module than `Monad`, then would
> have to import `Control.Monad.Fail` in addition to `Control.Monad` in order
> to be able to use partial pattern matching. You may argue that it is bad
> API design. Which would be fair, but it is hard to assume that such an
> event can't occur, when designing the compiler.
> >
> > > Neither of these arguments refute your underlying preference for
> > > records (which I would absolutely share – if we didn't need this
> ad-hoc
> > > “fully settled” and odd “any type works as long as it has the right
> > > fields”).
> > >
> > > I think it boils down to whether the goal (records) justify the kludges
> > > (fully settled, a desugaring that looks up some constructor K
> withoutusing it).
> >
> >
> > It's also a question of whether one would consider these as kludgy.  Or
> whether they sound rather natural to your ears. To me: rather natural,
> evidently. To you, and most other members of the committee, as far as I
> could gather, they seem to sound weird and somewhat repulsive.
> >
> > > (Can someone maybe just make GetField work with polytypes? Then we
> > > woudn’t have any of this discussion, I guess.)
> >
> >
> > Cheers to that :-)
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20200506/c87fe2b9/attachment.html>