November 2020 - ghc-steering-committee

#283: Local modules, recommendation: accept
by Spiwack, Arnaud 02 Nov '20

02 Nov '20

Dear all, I would like to bring our own Richard Eisenberg’s proposal, #283: Local modules, to your attention. https://github.com/ghc-proposals/ghc-proposals/pull/283 The proposal is an attempt at solving the long debated issue that we can’t export qualified names out of a module (*e.g.* we may have to repeat import qualified Data.Map as Map and import qualified Data.Set as Set in every module in a project, rather than simply calling import MyPrelude which would take care of both and more), to improve scope management, and sharing names between types in the same files, while making namespaces more convenient to use in the process. It’s a pretty ambitious proposal, with quite a few interlocking pieces. Yet, in my opinion, they fit pretty well together. And I’m, as a potential consumer, very enthusiastic about it. Some highlight (though do read the whole thing): - We can define modules inside of other modules, with the syntax module Foo (some, optional, exports) where … - Like in the rest of Haskell, modules are no more than namespaces. Therefore you can open two module Foo, it will just merge the names in them - Values in local modules can be referred to, qualified, in the encompassing module - Local modules can be exported, importing them will import the name as qualified - A new import module Foo statement can be used in let and where clauses, it brings everything of the form Foo.x into scope unqualified for the scope of the let or where Additionally, there is a small point that is not integral to the rest of the proposal, where defining, say, a type data T = A | B Would create a local module named T, such that the constructors could be referred to as T.A and T.B. I mention it separately, because it causes the only (small) backward incompatibility (that is Haskell 2010 programs which stop compiling when you turn on -XLocalModules). I’m rather in favour of keeping it in, but it’s worth mentioning. I pretty much want all of these features in my daily programming, so, as I said above, I’m very enthusiastic for all of this. And I’m pretty happy with the realisation. Hence my recommending acceptance. /Arnaud

5 9

Haskell 2020 Survey
by Joachim Breitner 02 Nov '20

02 Nov '20

Hi Committee, in case you didn’t see it: The yearly “State of Haskell Survey” at https://haskellweekly.news/survey/2020.html traditionally asked for “Which language extensions would you like to be enabled by default”. In pro-active anticipation of our GHC2020 process, they have changed the survey to let the community vote in favor, against, or abstain each extension. This should be sufficient for us to gauge whether there is interest in an extension being on by default, and whether there is contention about it. Just as Simon Marlow, I see no point in doing a very similar poll shortly after, and would just use the data coming out of that for GHC2021 (assuming we do the GHC2021 thing). I’ll say so (“If there is a GHC2021 language set, then the committee will very likely take the outcome of this poll into account.”) publicly, to encourage the community to take part in the survey. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Please review #372: The GHC20xx process, Shepherd: Simon PJ
by Joachim Breitner 02 Nov '20

02 Nov '20

Dear Committee, this is your secretary speaking: Alejandro and I have drafted a process for GHC20xx https://github.com/ghc-proposals/ghc-proposals/pull/372 https://github.com/ghc-proposals/ghc-proposals/blob/ghc20xx-process/proposa… propose Eric Seidel as the shepherd.b I’ll propose Simon PJ as the shepherd, as this is a procedural metaprocess that benefits from chair involvement. This is mostly the outcome of discussions we already had, so I don’t expect we need a lot of further discussion, and could maybe vote soon. Note that there are two alternatives in “2.2 Process“. They differ in the form the community is invited to be involved, and also in the overall weight of the process. The main difference is Do we want to _encourage_ broad discussion of individual extensions (the point of Alternative 2), because we believe it is useful and healthy, or do we want to avoid stirring such discussions (Alternative 1), because we don’t believe they would add much, would be distracting and time consuming, and because there is enough existing signal (the poll, reddit, the PR comment section, …). There are procedural differences that follow from that, e.g. using a separate repository (Alternative 2) or using our existing one (Alternative 1), but in a way the overall aim is the core of this alternative. Simon, once you think all interesting points have been raised (which may already be the case) I suggest you call for a ranked vote with the options “Reject”, “Alternative 1”, “Alternative 2”. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0