September 2023 - ghc-steering-committee

Fine-Grained Unused Warnings (#42)
by Chris Dornan 09 Sep '23

09 Sep '23

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 GHC currently warns equally about any superfluous binding that it discovers, regardless of whether the definition is unreferenced anywhere itself, or is merely mentioned by other definitions that are similarly superfluous. The proposal proposes to replace these warnings with just the warnings about definitions that are not referenced anywhere, but list within those warnings the entities it references that would otherwise not be required. The same information is being conveyed under this proposal as previously, but in a more structured manner. The proposal is careful to ensure the -Wunused-* controls (-Wunused-top-binds, etc.) are respected, so the subwarnings of transitively unused entities are only listed if their corresponding -Wunused-* control is active. As Jakob points out in the proposal, getting these warnings into some structure is partly motivated by IDE usage where the 'additional [transitive] warnings take up a lot of valuable screen real estate'. ## Example [From the proposal] In the following code, module Foo () import Data.List as L foo = L.intercalate `intercalate` is transitively unused, since it is only used by `foo`, which is unused. The warning that's produced will be Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ as a consequence the following imports are transitively unused [-Wunused-imports]: Data.List imported at foo.hs:3:1: The warning about transitively unused bindings only appears if both the warning flag for the unused binding (in this case -Wunused-top-binds) and the the one for the transitively unused binding itself (in this case -Wunused-imports) are enabled. ## Recommendation This proposal is not at all disruptive (arguably to the extent of not requiring a GHC proposal review), is well thought out, and can improve the GHC/IDE UI so I recommend that we accept it.

4 4

GHC Steering Committee Status
by Joachim Breitner 04 Sep '23

04 Sep '23

Dear Committee, time for another status email, in particular because I need an up-to-date update to get stats for Simon’s famous report at HIW on Monday. Hope to see some of you there! Let’s see what has happened since July 3 * Arnaud did round 3 of his language extension policy investigation. * we were asked to review these proposals: #597: Constraints synonyms in deriving heads, Shepherd: Moritz #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, Sepherd: Joachim #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard #583: HasField redesign, Shepherd: Arnaud #609: (p1; p2) for or-patterns, Shepherd: Chris #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad #605: visible forall to work without ScopedTypeVariables, Shepherd: Joachim #601: Extension lifecycle, Shepherd: Simon PJ * we have a recommendation from the shepherd about: #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept #605: visible forall to work without ScopedTypeVariables, rec: accept #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept) #583: HasField redesign, rec: accept #601: Extension lifecycle, rec: accept * we have sent the following proposals back to revision #601: Extension lifecycle * we decided about the following proposals #596: sized literals in Show, accept #581: Namespaces-specified Imports, accept #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept) #605: visible forall to work without ScopedTypeVariables, accept So we currently have to act on the following 9 proposals, up one since last time: ## Waiting for committee decision #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad 2022-09-03: Assigned to Baldur 2022-10-02: Reassignd to Vlad 2022-11-30: Vlad recommends rejection This needs to be picked up again, it has been lingering too long! #536: Type-level literals as a sep language extension, Shepherd: Vlad 2023-02-16 Assigned to Vlad 2023-03-06 Vlad recommends acceptance Some hesitancy in the committee to introduce this extension, the ongoing policy clarification process might guide us, but maybe we can resolve this earlier? #583: HasField redesign, rec: accept 2023-08-30 Arnaud recommends acceptance ## Waiting for shepherd recommendation #526: Applicative Comprehensions, Shepherd: Simon M 2022-10-08: Assigned to Simon M Simon, please cast your recommendation! #585: Amend Or Patterns, Shepherd: Richard 2023-04-11: Assigned to Richard There are votes on syntax going on, ran by Sebastian Graf. Maybe this should be in “needs revision” until they are through. Richard, I’ll leave this to you #609 seems to be related, not sure if we need both. #194: Updated partial type signatures, Shepherd: Eric 2023-05-25: Came back from needs revision #434: Fine-grained unused warnings, Shepherd: Chris 2023-07-02: Assigned to Chris #597: Constraints synonyms in deriving heads, Shepherd: Moritz 2023-07-25: Assigned to Moritz #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard 2023-08-17: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3

Please review #601: Extension lifecycle, Shepherd: Simon PJ
by Joachim Breitner 03 Sep '23

03 Sep '23

Dear Committee, David Thrane Christiansen suggested to categorize extensions into Experimental, Mature, Deprecated and Legacy, and add warning flag to GHC that allow users to be warned about (or shouted at for) using such extensions, if they choose so. https://github.com/ghc-proposals/ghc-proposals/pull/601 https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycl… Because of the meta-like aspect of this proposal, I’d like to assign this to Simon PJ. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

10 22

Please review #194: Updated partial type signatures, Shepherd: Eric
by Joachim Breitner 02 Sep '23

02 Sep '23

Dear Committee, Richard resubmits updated partial type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/… I’d like to ask Eric to shepherd this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 4

#607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
by Vladislav 02 Sep '23

02 Sep '23

Dear Committee, Jakob Brünker has proposed #607, an amendment to proposals #281 (visible forall) and #378 (Design of DH). See the diff here: <https://github.com/ghc-proposals/ghc-proposals/pull/607/files> The amendment concerns type checking of term-level variables appearing in types, for example: f :: forall (a :: Bool) -> ... -- visible forall, `f` expects a type-level Bool g :: Bool -> ... -- ordinary arrow, `g` expects a term-level Bool g x = f x What should happen to `x`, bound as a term variable but used as a type? #378 "Design for Dependent Types" already has an answer to this question: treat `x` as a skolem. But there are two problems 1. #378 does not explain this design decision in sufficient detail. This led Simon to question its inclusion: "Does it have any value, really? Why not just reject?" 2. #281 follows this design in one section, saying "treated as a fresh skolem constant"; and rejects it in another section, saying "any uses of terms in types are ill-typed". There is a contradiction. The amendment addresses both issues as follows: 1. A new example is added to #378, explaining how treating `x` as a skolem is useful, but only if `foreach` is available (a retained quantifier that allows dependent pattern matching) 2. Contradiction in #281 is resolved in favor of rejecting any uses of terms in types as ill-typed, saving this feature for a future proposal. I recommend to accept. Please share your thoughts either here or directly on GitHub. Vlad

7 7

#605: visible forall to work without ScopedTypeVariables, rec: accept
by Joachim Breitner 02 Sep '23

02 Sep '23

Dear committee, Vladislav Zavialov in https://github.com/ghc-proposals/ghc-proposals/pull/605 proposes a small fix to #281, namely that for f :: forall x -> Show x => x -> String f (type t) = show @t to work, ExplicitNamespaces and RequiredTypeArguments is sufficient, and we should not also require ScopedTypeVariables, which we are moving away from. I’ll shepherd this myself, and I suggest acceptance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5