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

Wed May 6 14:56:33 UTC 2020

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