[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative
Simon Peyton Jones
simonpj at microsoft.com
Wed May 6 15:45:18 UTC 2020
Yes, I'm just saying I'd like to see the actual final proposal we are being asked to approve before approving it.
You pointed to a previous version. But the current version doubtless has been improved in various ways ... let's not lose that. Eg I'd love to see the careful wording about fully settled types appear in the 'builder' alternative section. It's already written .. I'm not suggesting new work.
not a big deal!
Simon
| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 06 May 2020 16:31
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] #216: Qualified Do again,
| recommendation: accept the alternative
|
| 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/
|
|
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
More information about the ghc-steering-committee
mailing list