April 2024 - ghc-steering-committee

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

#632: Phased introduction of GHC2024
by Adam Gundry 22 Apr '24

22 Apr '24

Dear committee, In #632, I propose amending the GHC2024 proposal to specify that the default language used by ghc/ghci when run directly will remain GHC2021 for now, since changing to GHC2024 is not backwards compatible. (This does not affect Cabal packages either way, since Cabal specifies its own default.) https://github.com/ghc-proposals/ghc-proposals/pull/632 https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposal… On the discussion thread, some people expressed a preference that GHC should default to the latest language edition anyway. There is also Richard's suggestion of wider changes of approach in #636. However, given that the GHC 9.10 fork date is fast approaching, introducing GHC2024 but not making it the default seems like the best short-term solution to me. We can always reassess our approach to this for future releases as part of the wider discussion. If you object to the proposed approach, please speak up ASAP. Otherwise I plan to merge in a week or so. 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 20

Fine-Grained Unused Warnings (#42)
by Chris Dornan 19 Apr '24

19 Apr '24

Proposal: Fine-Grained Unused Warnings (#42) Author: Jakob Brünker Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/pro… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434 Recommendation: Acceptance ## Summary The proposal partitions warning about unused identifiers into a) bindings that are truly unused (not mentioned anywhere) and b) bindings that are mentioned exclusively in code that is itself (transitively) unused, and suppresses the latter unless the -freport-indirectly-unused-bindings flag is specified. The proposal is concise with some well-chosen examples and I recommend everyone at least skim it. I propose that we accept this proposal if nobody objects by the start of next week (Monday, 2024-02-19). Chris

6 14

Please review #640: Fix quantification order for a `op` b and a %m -> b
by Adam Gundry 16 Apr '24

16 Apr '24

Dear Committee, Vlad proposes to change the order of implicit quantification for type variables occurring as type operators or in multiplicity annotations: https://github.com/ghc-proposals/ghc-proposals/pull/640 https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantificati… I'd like to nominate Malte as the shepherd (welcome Malte!). 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

8 15

Proposal #638: Prefix form for MkSolo# (Recommend Accept)
by Matthías Páll Gissurarson 14 Apr '24

14 Apr '24

Greetings committee! In [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/638), @int-index proposes that we introduce a prefix form of MkSolo#, and apparent oversight in proposal #475 [Non-punning list and tuple syntax]( https://github.com/ghc-proposals/ghc-proposals/pull/475) Previously, you would write `(# a #)` to construct a `Solo# a`. But the question is: what would be the prefix form of this constructor? It can't be `(# #)`, because this is already defined as a constructor of `Unit#`! This amendment proposes the `MkSolo#` constructor, having us write `MkSolo# a` for the prefix form. The discussion seems unanimous, after care was taken to clarify that a fully applied `MkSolo# a` would still be pretty printed as `(# a #)`, avoiding programmer confusion. It seems quite straightforward to me, so: I recommend accepting this amendment to #475. -- -- Matthías Páll Gissurarson <http://mpg.is/>

5 11