October 2020 - ghc-steering-committee

Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
by Joachim Breitner 08 Jan '22

08 Jan '22

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/propos… I propose Eric Seidel as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 18

Proposal #302: `\of`
by Richard Eisenberg 01 Jul '21

01 Jul '21

Hi all, Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves. PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-… Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075… The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea: mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y) The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual. I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time. Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax. Richard

10 29

Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
by Joachim Breitner 19 Mar '21

19 Mar '21

Dear Committee, this is your secretary speaking: Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals… I’ll propose Simon Marlow as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 9

Please review #369: Add sumToTag# primop, Shepherd: Eric
by Joachim Breitner 18 Feb '21

18 Feb '21

Dear Committee, this is your secretary speaking: Add sumToTag# primop has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/369 https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum… I’ll propose Eric Seidel as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 8

Steering Committee bylaws
by Richard Eisenberg 22 Jan '21

22 Jan '21

Hi all, Some time ago, I posted https://github.com/ghc-proposals/ghc-proposals/pull/360 <https://github.com/ghc-proposals/ghc-proposals/pull/360>, an attempt at crafting bylaws for this committee. Conversation has died down, and so I'd like to have a discussion that will lead to amendments and then eventual acceptance (of something). I think it's best for this discussion to be right on the PR, not this thread. However, given that this PR is all about how we function, as a committee, I would like to see participation (ideally, agreement!) from everyone here before proceeding, even if it's just a LGTM. Thanks! Richard

8 10

Please review #313: Delimited continuation primops, Shepherd: Simon Marlow
by Joachim Breitner 18 Jan '21

18 Jan '21

Dear Committee, this is your secretary speaking: Delimited continuation primops has been proposed by Alexis King https://github.com/ghc-proposals/ghc-proposals/pull/313 https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-pr… I’ll propose Simon Marlow as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 14

#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

Status
by Joachim Breitner 27 Oct '20

27 Oct '20

Dear Committee, another “regular” status update. So what has happened in the last two months? * Lots of discussion about GHC2020. Enough to make it rather GHC2021. * Richard refines the bylaws in #360. Maybe everybody has a second look now and then we can merge this? * we were asked to review these proposals: #356: Linear Types arrow, shepherd: Richard #351: NoIncomplete, shepherd: Iavor #364: Unify Nat and Natural, shepherd: Alejandro #283: Local modules, Shepherd: Arnaud #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow #369: Add sumToTag# primop, Shepherd: Eric * we have a recommendation from the shepherd about: #302: \of (rec: reject) #356: Linear Types arrow (rec: vote) #364: Unify Nat and Natural (rec: accept) #281: Visible 'forall' in types of terms (rec: accept) #283: Local modules (rec: accept) * we have sent the following proposals back to revision #281: Visible 'forall' in types of terms * we decided about the following proposals #356: Linear Types arrow (accept) #364: Unify Nat and Natural (accept) We currently have to act on the following 5 proposals, up by 3. ## Waiting for committee decision #313: Delimited continuation primops, Shepherd: Simon Marlow #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow ## Waiting for Shepherd action #333: Defer Parse Errors, Shepherd: Tom Tom, is this ready for Committee consideration? #302: Layout and Guards in Lambda Expressions, Shepherd: Cale Cale, it is high time to jump into action here! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

Status (complete)
by Joachim Breitner 27 Oct '20

27 Oct '20

[previous message was sent prematurely, sorry] Dear Committee, another “regular” status update. So what has happened in the last two months? * Lots of discussion about GHC2020. Enough to make it rather GHC2021. * Richard refines the bylaws in #360. Maybe everybody has a second look now and then we can merge this? * we were asked to review these proposals: #356: Linear Types arrow, shepherd: Richard #351: NoIncomplete, shepherd: Iavor #364: Unify Nat and Natural, shepherd: Alejandro #283: Local modules, Shepherd: Arnaud #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow #369: Add sumToTag# primop, Shepherd: Eric * we have a recommendation from the shepherd about: #302: \of (rec: reject) #356: Linear Types arrow (rec: vote) #364: Unify Nat and Natural (rec: accept) #281: Visible 'forall' in types of terms (rec: accept) #283: Local modules (rec: accept) * we have sent the following proposals back to revision #281: Visible 'forall' in types of terms * we decided about the following proposals #356: Linear Types arrow (accept) #364: Unify Nat and Natural (accept) We currently have to act on the following 5 proposals, up by 3. ## Waiting for committee decision #283: Local modules, Shepherd: Arnaud Mostly positive, may need more revision though #302: \of, Shepherd: Cale Mostly negative, but still discussion going on. ## Waiting for Shepherd action #313: Delimited continuation primops, Shepherd: Simon Marlow This one is aging. Simon, are you on this? #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Still rather new. #369: Add sumToTag# primop, Shepherd: Eric Still rather new. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Re: [ghc-steering-committee] GHC 2020
by Alejandro Serrano Mena 27 Oct '20

27 Oct '20

I would really like this effort not to die, so I've given the proposal another push. Following the comments from Simon and Joachim, I've re-framed the proposal as laying down a process to create new "language versions" yearly. The idea is to have one of these every year (or 2, or 3, whatever is decided), coinciding with the spring release of GHC. https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-20… I think it's important for the community to be involved in the process. If it's clear that an extension is loved by most of the community, that's a big plus for acceptance. In addition, if we come with a list ourselves, we risk having made choices which only show our (biased) point of view. Since in the first round the possible list of extensions may be quite big, we might introduce a "fast-lane process" for this one time, for extensions like EmptyDataDecls or different number formats which seem to have unanimous support. Looking forward to hearing from all of you, Alejandro El lun., 5 oct. 2020 a las 12:07, Joachim Breitner (< mail(a)joachim-breitner.de>) escribió: > Hi, > > Am Montag, den 05.10.2020, 10:21 +0100 schrieb Simon Marlow: > > > Personally, I would also like to come up with general guidance. Do > > > we expect *any* extension fulfilling the criteria to be included? > > > > > > > Let's be conservative: if there's controversy around a particular > > extension, default to not including it in GHC2020. > > that was a core idea of my original process proposal: > > Without long, time-consuming and process-heavy debate around each > extension, let’s all of us individually assemble a list of extensions, > and turn that into GHC2020. (Maybe for extensions that were not on the > list by only one or two give them a chance to reconsider). > > This way there is still a chance that it'd become GHC2020, and not > GHC2021 or GHC2022, or just fizzle… > > And it would hopefully be the a GHC2020 that contains all the low- > hanging, non-controversial fruit. This also means that GHC2020 has a > good chance of actually getting used. Which means for the work for > GHC2021, picking the next set of extensions, is actually relevant and > meaningful. > > > And if something doesn’t make it into GHC2020 that maybe should have? > No big deal, as Simon says. > > Cheers, > Joachim > > > > -- > Joachim Breitner > mail(a)joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >

5 16