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 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/2a1dcc29cc9db7a1f4e86b6cfb86d87c...

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 On Behalf Of Joachim Breitner Sent: 06 May 2020 14:52 To: ghc-steering-committee@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 On Behalf Of Spiwack, Arnaud Sent: 05 May 2020 09:32 To: Joachim Breitner Cc: ]Ghc steering committee 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@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@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- 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

_______________________________________________ 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/