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

Wed May 6 15:30:32 UTC 2020

Hi,

anyways, I’ll ask the authors to update the proposal, and notify the
committee for a brief glance before it gets merged.

Cheers,
Joachim

Am Mittwoch, den 06.05.2020, 15:56 +0100 schrieb Richard Eisenberg:
> For me, the key point is that the proposal as merged into `master` is the correct, final proposal. I don't think we need a re-review after that is done, but I wouldn't want to just merge a proposal that's not in its final state.
> 
> Richard
> 
> > On May 6, 2020, at 3:30 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > hmm, is that necessary? I think all we are saying is “your previous
> > submission was actually fine”. Nothing has changed since then, as far
> > as I can tell. That version is, I believe, this one:
> > 
> > https://github.com/tweag/ghc-proposals/blob/2a1dcc29cc9db7a1f4e86b6cfb86d87cfa72c1cd/proposals/0000-local-do.rst
> > 
> > But we can ping the committee once more, if you think that’s helpful.
> > 
> > Cheers,
> > Joachim
> > 
> > 
> > 
> > Am Mittwoch, den 06.05.2020, 14:02 +0000 schrieb Simon Peyton Jones via
> > ghc-steering-committee:
> > > I'd rather see a final edit of the proposal, reflecting the final choices, before formally tying the bow.
> > > 
> > > We did that with record dot syntax
> > > 
> > > S
> > > 
> > > > -----Original Message-----
> > > > From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > > > On Behalf Of Joachim Breitner
> > > > Sent: 06 May 2020 14:52
> > > > To: ghc-steering-committee at haskell.org
> > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again,
> > > > recommendation: accept the alternative
> > > > 
> > > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> > > > com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local-
> > > > do.rst%23do-with-a-module-
> > > > name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d
> > > > 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686
> > > > &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved=
> > > > 0
> > > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha
> > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005
> > > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936
> > > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re
> > > > served=0
> > > > --
> > > > Joachim Breitner
> > > >   mail at joachim-breitner.de
> > > > 
> > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac
> > > > him-
> > > > breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514
> > > > 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369
> > > > 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a
> > > > mp;reserved=0
> > > > 
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha
> > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005
> > > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936
> > > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re
> > > > served=0
> > > _______________________________________________
> > > 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
> 
> _______________________________________________
> 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/