- ghc-steering-committee

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

Request for Nominations to the GHC Steering Committee
by Alejandro Serrano Mena 13 Feb '21

13 Feb '21

Dear Haskell community, The three-year term limit of some of the GHC Steering committee members has expired. We are really grateful for the awesome work that Iavor, Richard, and Joachim have done through these years (especially the latter, who has acted as secretary.) As a result, the GHC Steering committee is seeking nominations for new members. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for members who have the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the interim committee secretary) at trupill at gmail.com until February 28th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Alejandro Serrano

1 0

Please review #390: Fine-grained pragmas, Shepherd: Vitaly
by Joachim Breitner 09 Feb '21

09 Feb '21

Dear Committee, this is your secretary speaking: Fine-grained pragmas for classes, families, and instances has been proposed by Alejandro https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/000… I’ll propose Vitaly Bragilevsky 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/

2 1

Expiring members: Simons, Iavor, Richard, Me
by Joachim Breitner 08 Feb '21

08 Feb '21

Dear committee, with the refined bylaws merged at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst we now have a three year term limit. Luckily I have always tracked when each of us started, at https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee so it is easy to see that the following members’s terms have expired: Iavor, Richard, Simon², me The rules are slightly different for the Simons (“key members”) and the rest of us. Simons: Do you want to stay on the committee? If you say yes, the committee does a simple majority vote to confirm that. Iavor, Richard, Joachim: We three are lame ducks now: We are now “expiring members”, we are only on the committee until the end of now triggered public call for nominations. We three are eligible to re-nominate ourselves, of course. With three expiring members we are down to 7 active members (less if one of the Simons does not want to stay on). This means a call for nominations is triggered now. I think I’ll send it out on the weekend. The text of the previous was this: https://mail.haskell.org/pipermail/haskell/2019-December/025880.html Let me know if you want me to use a different text. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 11

Please review #368: Warn on prefix/suffix operators, Shepherd: Tom
by Joachim Breitner 02 Feb '21

02 Feb '21

Dear Committee, this is your secretary speaking: Warn on prefix/suffix operators has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/368 This is an amendment to #229 (Whitespace-sensitive operator parsing), see the PR description linked above for details. I’ll propose Tom 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 6

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 #387: The Char kind, Shepherd: Alejandro
by Joachim Breitner 22 Jan '21

22 Jan '21

Dear Committee, this is your secretary speaking: The Char Kind has been proposed by Daniel Rogozin https://github.com/ghc-proposals/ghc-proposals/pull/387 https://github.com/serokell/ghc-proposals/blob/master/proposals/0000-char-k… I’ll propose Alejandro 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/

4 5

#380 GHC2021: Voting starts
by Joachim Breitner 18 Jan '21

18 Jan '21

Dear Committee, the requested data (hackage and survey) is in, has been aggregated, cooked, seasoned and is ready for consumption. 116 extensions are waiting on your assessment, so time to vote! ## Procedure Please vote by email to this list, in a response to this thread. I want to make tallying easy and automatic, and my code will consider an extension Foo voted for if you write "Foo: yes" on its own line. This means you can include rationales, write "Foo: maybe" and "Foo: no" to remind yourself and others that about where you are, and you can safely quote other’s mails. For example, if you write: ---- begin example ---- Easy ones: DeriveFooBar: yes OverloadedBen: no These ones are tricky: ImplicitExceptions: yes I know nobody likes that one, but I do. RandomEvaluationOrder: maybe Not sure about this one, here is why… > Richard wrote: > DependentHaskell: yes > Rationale: See my thesis I’m not convinced yet, tell me more, so DependentHaskell: maybe ---- end example ---- then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” matters, “no”, “maybe” and “later” are all ignored. I will shortly send my first ballot around. Also see the end of this mail for a copy’n’paste template. You can update your vote as often as you want. Please always send your full votes (I will only consider your latest email). I encourage you to do that early, e.g. maybe start with a mail where you list the obvious yes and nos, and keep some at maybe and then refine. The timeline says first votes should be in within two weeks, and then a bit more to refine. But the earlier the merrier! The quota is 8. In particular, if everyone votes (and I hope everyone will), an extension won’t make it this round if 4 don’t include it. ## Data Please see https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-… for the data, including explanations. It is intentionally not sorted by the data, as the choice of ranking function would already be quite influencing. You may want to play around with that data, e.g. sort it by your own criteria etc. I looked long for an online service where I can upload the data and allow you to explore it, but then I noticed that that's a bit stupid, since we all probably can do it best with Haskell. So I made it easy to load the data into GHCi, see the instructions at https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README… which allow you, for example, to do this *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) AllowAmbiguousTypes: 195 CPP: 192 IncoherentInstances: 176 Arrows: 156 Strict: 153 ImplicitParams: 147 UndecidableInstances: 144 OverlappingInstances: 144 Unsafe: 139 TemplateHaskell: 137 Of course, if someone wants to upload the data somewhere and share that, that's also useful. Let me know if some of this doesn't quite work for you, and should be improved. Maybe we need a web form instead of mails? ## PS: Blank ballot To start, you could copy the following into an email AllowAmbiguousTypes: maybe ApplicativeDo: maybe Arrows: maybe BangPatterns: maybe BinaryLiterals: maybe BlockArguments: maybe CApiFFI: maybe CPP: maybe CUSKs: maybe ConstrainedClassMethods: maybe ConstraintKinds: maybe DataKinds: maybe DatatypeContexts: maybe DefaultSignatures: maybe DeriveAnyClass: maybe DeriveDataTypeable: maybe DeriveFoldable: maybe DeriveFunctor: maybe DeriveGeneric: maybe DeriveLift: maybe DeriveTraversable: maybe DerivingStrategies: maybe DerivingVia: maybe DisambiguateRecordFields: maybe DuplicateRecordFields: maybe EmptyCase: maybe EmptyDataDecls: maybe EmptyDataDeriving: maybe ExistentialQuantification: maybe ExplicitForAll: maybe ExplicitNamespaces: maybe ExtendedDefaultRules: maybe FlexibleContexts: maybe FlexibleInstances: maybe ForeignFunctionInterface: maybe FunctionalDependencies: maybe GADTSyntax: maybe GADTs: maybe GHCForeignImportPrim: maybe GeneralisedNewtypeDeriving: maybe HexFloatLiterals: maybe ImplicitParams: maybe ImportQualifiedPost: maybe ImpredicativeTypes: maybe IncoherentInstances: maybe InstanceSigs: maybe InterruptibleFFI: maybe KindSignatures: maybe LambdaCase: maybe LexicalNegation: maybe LiberalTypeSynonyms: maybe LinearTypes: maybe MagicHash: maybe MonadComprehensions: maybe MonadFailDesugaring: maybe MonoLocalBinds: maybe MultiParamTypeClasses: maybe MultiWayIf: maybe NPlusKPatterns: maybe NamedFieldPuns: maybe NamedWildCards: maybe NegativeLiterals: maybe NoImplicitPrelude: maybe NoMonomorphismRestriction: maybe NoPatternGuards: maybe NoTraditionalRecordSyntax: maybe NondecreasingIndentation: maybe NullaryTypeClasses: maybe NumDecimals: maybe NumericUnderscores: maybe OverlappingInstances: maybe OverloadedLabels: maybe OverloadedLists: maybe OverloadedStrings: maybe PackageImports: maybe ParallelListComp: maybe PartialTypeSignatures: maybe PatternSynonyms: maybe PolyKinds: maybe PostfixOperators: maybe QualifiedDo: maybe QuantifiedConstraints: maybe QuasiQuotes: maybe RankNTypes: maybe RebindableSyntax: maybe RecordWildCards: maybe RecursiveDo: maybe RoleAnnotations: maybe Safe: maybe ScopedTypeVariables: maybe StandaloneDeriving: maybe StandaloneKindSignatures: maybe StarIsType: maybe StaticPointers: maybe Strict: maybe StrictData: maybe TemplateHaskell: maybe TemplateHaskellQuotes: maybe TransformListComp: maybe Trustworthy: maybe TupleSections: maybe TypeApplications: maybe TypeFamilies: maybe TypeFamilyDependencies: maybe TypeInType: maybe TypeOperators: maybe TypeSynonymInstances: maybe UnboxedSums: maybe UnboxedTuples: maybe UndecidableInstances: maybe UndecidableSuperClasses: maybe UnicodeSyntax: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe Unsafe: maybe ViewPatterns: maybe -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

12 159

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

Status
by Joachim Breitner 18 Jan '21

18 Jan '21

Dear Committee, after 2½ months, time for a new status updates. What was going on here? * Well, GHC2021 was going on. Lots of it. But it’s actually coming to a close in five days. It will be exciting to see how it affects the Haskell landscapes. * Heh, last status I wrote: Richard refines the bylaws in #360. Maybe everybody has a second look now and then we can merge this? I guess that still applies. Richard and I are discussing a corner case on the PR, but otherwise approvals are coming in, and unless that changes, we’ll merge that once we ironed out that wrinkle. * Simon introduced the position of a nudger, namely Tom. Tom, below are some PRs where you might need to nudge someone! * we were asked to review these proposals: #366: DuplicateRecordFields without ambiguous field access, shepherd: Tom #242: Unsaturated type families, Shepherd: Richard Eisenberg #370: Syntax for Modifiers, Shepherd: Alejandro #387: The Char kind, Shepherd: Alejandro #368: Warn on prefix/suffix operators, Shepherd: Tom #381: Visible 'forall' in types of terms, Shepherd: Iavor * we have a recommendation from the shepherd about: #369: Add sumToTag# primop, (rec: accept) #366: DuplicateRecordFields without ambiguous field access (rec: accept) #381: Visible 'forall' in types of terms (rec: reject) #242: Unsaturated type families (rec: accept) #313: Delimited continuation primops (rec: accept) #370: Syntax for Modifiers (rec: accept) #387: The Char kind (rec: accept) * we have sent the following proposals back to revision #283: Local modules * we decided about the following proposals #366: DuplicateRecordFields without ambiguous field access (accept) #370: Syntax for Modifiers (accept) #242: Unsaturated type families (accept) In addition to the two meta-proposals (bylaws and GHC2021), we currently have to act on the following 7 proposals, up by 2! Some need some nudging. ## Waiting for committee decision #387: The Char kind, Shepherd: Alejandro Looks like it’ll be smoothly accepted, but it’s only a week old. Will maybe merge in a few days. #381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? #369: Add sumToTag# primop Essentially accepted, waiting for feedback from the author on final tweaks #313: Delimited continuation primops, Shepherd: Simon Marlow Mostly positive reception, but there was discussion. Simon, can this be accepted as it, or does it need more work/time/discussion? #302: \of, Shepherd: Cale No new discussion. Cale, what is the conclusion? ## Waiting for Shepherd action #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow This is aging… we need a shepherd recommendation #368: Warn on prefix/suffix operators, Shepherd: Tom Tom, your turn Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 3