May 2024 - ghc-steering-committee

Proposal #601: extension lifecycle
by Simon Peyton Jones 04 Jun '24

04 Jun '24

Dear GHC Steering Committee Trevis Elser has submitted GHC Proposal #601 <https://github.com/ghc-proposals/ghc-proposals/pull/601>to us for consideration. (It was originally drafted by David Christiansen, but Trevis took it over.) It proposes that that we classify extensions into four categories: - Stable - Experimental - Deprecated - Legacy It does not say which extensions are in which category (that's #635, still to come); it simply establishes the categories. *I strongly urge you to accept the proposal*. We have been using this language informally for years, and it's good to nail it down more precisely. There is plenty of discussion on the PR, but it's all about the specifics (e.g. do we want both Deprecated and Legacy; answer, yes). There seems to be a strong consensus around the principle. I don't expect this to be controversial. Please (everyone) can you respond within a week, by *end of day on Thursday 23 May. *Can you - Reply by email - Update the spreadsheet <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu…>with your vote Thanks! Simon

8 10

Please review #267: Class method headers
by Adam Gundry 24 May '24

24 May '24

Dear Committee, Vlad proposes to allow class variable binders on the left of :: in class method signatures: https://github.com/ghc-proposals/ghc-proposals/pull/267 https://github.com/int-index/ghc-proposals/blob/class-method-headers/propos… I'd like to nominate Jakob as the shepherd (welcome Jakob!). Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

1 0

Welcome to new members
by Adam Gundry 16 May '24

16 May '24

Dear all, Following the recent nomination round, the committee is delighted to welcome Sebastian Graf, Jakob Brünker and Erik de Castro Lopo as new members. Thank you for your willingness to volunteer. I will add your details to the GitHub repo, and you are encouraged to contribute to the discussion of any of the proposals under committee review. We would also like to record our thanks to those who applied in this round but were not selected. It was unusually competitive, so we were unfortunately not in a position to accept everyone, but your continued involvement in the proposals process is very welcome, and there will no doubt be future opportunities to join the committee. Best wishes, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

3 3

Please review #641: Wildcard binders in type declarations
by Adam Gundry 13 May '24

13 May '24

Dear Committee, Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641 I'd like to nominate Simon PJ as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

9 33

Proposal #631: Set program exit code by main return type, recommendation: accept something
by Arnaud Spiwack 03 May '24

03 May '24

Dear all, Shea Levy proposes to do something with the values returned by `main` https://github.com/ghc-proposals/ghc-proposals/pull/631 . The problem is that `main` is allowed to be of type `IO A` for any `A`. And GHC will simply drop the value returned by `main`. Shea contends that it's surprising. I agree that dropping a value without the compiler being explicitly instructed to is surprising. But Shea says that when `A` is `ExitCode` this is even more surprising. Namely `main :: IO ExitCode; main = return $ Failure 1` actually terminates with exit code 0. And I doubt that it's what anybody expects when reading the code. The proposal is simple, but I have a lot of comments on it. Sorry about that… Now, this sort of proposal is tricky. When the current behaviour is confusing, we want to change the default. But putting the new default behind an extension doesn't really solve the fact that there's a trap. The extension is, therefore, unlikely to be well tested before it becomes part of the next language edition. Shea's main proposition doesn't actually use an extension though. He adds a type class `ExitStatus`, and if `ExistStatus A`, then `main :: IO A` uses the instance to determine the exit code based on the return value. The only change to the current behaviour is that `main :: IO ExitCode` instead of always terminating with exit code 0 when returning now terminates with the expected error code. The argument for not putting this behind an extension is that virtually anybody affected by the change will actually have the behaviour they were expecting. But maybe the argument isn't strong enough (the changes may be more “interesting” if some library exports some `ExistStatus` instance). This design of this proposal is inspired by Rust's design. I've asked our Rust team, and they certainly seem to have internalised the idea of returning an exit code. It really seems a pretty natural feature to have. So I'm rather in favour of some flavour of the type class implementation. Though have a look at the alternatives, where you'll find other approaches such as restricting the type of `main` to unsurprising types. One caveat with respect to the main proposal: it is proposed that when no `ExistStatus A` is found, then we drop the returned value like today. I don't know that it's quite easy to implement this behaviour. But it can be recovered by a catch-all overlapping instance, so maybe it's a better way to specify the desired behaviour. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

10 37