[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative
Joachim Breitner
mail at joachim-breitner.de
Wed May 6 14:30:41 UTC 2020
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/
More information about the ghc-steering-committee
mailing list