[ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative
Simon Peyton Jones
simonpj at microsoft.com
Wed May 6 14:02:58 UTC 2020
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
More information about the ghc-steering-committee
mailing list