September 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

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

Please review #364: Unify Nat and Natural, Shepherd: Alejandro
by Joachim Breitner 12 Oct '20

12 Oct '20

Dear Committee, this is your secretary speaking: Unify Nat and Natural has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/364 https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-uni… 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/

6 9

GHC 2020
by Iavor Diatchki 04 Oct '20

04 Oct '20

Hello, I just had some fun and went through the list of GHC extensions in the manual, thinking of which ones might make a reasonable subset for a potential GHC2020. Below is the list I came up with. My reasoning was, roughy: * I wouldn't mind if these were on all the time * It is unlikely that turning on the extension will break something dramatically * It is unlikely that using the extension might lead to errors * The extensions are somewhat coherent * I explicitly included extensions that I personally don't use much, but I've heard that others like I wonder what others think of this list? What would you add/remove? -Iavor BlockArguments EmptyCase EmptyDatadecls ExplicitNamespaces ImportQualifiedPost LambdaCase MultiWayIf StandaloneDeriving BinaryLiterals HexFloatLiterals NumericUnderscores NamedFieldPuns RecordWildCards TupleSections ApplicativeDo RecursiveDo ParallelListComp BangPatterns PatternSynonyms ViewPatterns PatternGuards ForeignFunctionInterface CApiFFI RankNTypes ExistentialQuantification ScopedTypeVariables TypeSynonymInstances ConstraintKinds StandaloneKindSignatures KindSignatures TypeOperators

8 39

The 'Char' kind
by Richard Eisenberg 21 Sep '20

21 Sep '20

Hi GHCSC, Before this committee existed, Alex Vieth submitted #11342 (https://gitlab.haskell.org/ghc/ghc/-/issues/11342 <https://gitlab.haskell.org/ghc/ghc/-/issues/11342>), requesting a kind `Char`. Serokell has now provided a patch, !3598 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598>). The chair of the CLC has signed off on this patch (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598#note_300231>). But I feel we should, too. What is a good process here? Just debate amongst ourselves? Post a GitHub Issue to call wider attention? Post a proposal? Merge without debate? Richard

3 2

Proposal #356: new syntax for linear arrows
by Richard Eisenberg 18 Sep '20

18 Sep '20

Hi committee, Mathieu Boespflug has proposed a new syntax for linear arrows: https://github.com/ghc-proposals/ghc-proposals/pull/356 Currently (from the original linear types proposal), we have #-> to denote a linear function, and # m -> to denote an arbitrary function whose argument has multiplicity m. This proposal suggests three changes: 1. Drop #-> entirely. 2. Use ^ instead of # in the second form, but require that it be a *prefix* usage of ^ (that is, the character after the ^ must not be whitespace). 3. Introduce a new lexeme ^1 that is used to denote linear functions. Alternative: use % in place of ^; % is observed to be more visually apparent in some fonts than ^. In time, the hope is that rule (3) will no longer be needed, if we gain overloaded numbers at the type level (when 1 :: Multiplicity will type-check without a special rule). Motivations for this change come from the experience within Tweag of using linear types. The change away from # also is to avoid a conflict with overloaded labels, once those are allowed in types. The hope is that we can make a decision about this in time for release with GHC 9.0. This proposal is already implemented: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4020 In conflict with our usual protocol, I will not make a recommendation on this proposal, as I am conflicted with the proposer. However, I do hope that we can come to a conclusion on this quickly, to avoid making a backward-incompatible change after a release. We have four options: A. Keep the syntax as it is. B. Choose to go with ^ C. Choose to go with % D. Choose to go with some other symbol. I don't think there is any particular preference for any one symbol over another. Richard

6 6

Goals for GHC
by Simon Peyton Jones 11 Sep '20

11 Sep '20

Dear GHC Steering Committee Dmitrii makes a good point about GHC in this blog post. To discuss. Simon * Be a goalkeeper<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnews.us10…> by Dmitrii Kovanikov You may find this blog post useful, if you are interested in maintaining any project for a long time and keep your sanity during this process.

3 2

Please review #351: NoIcomplete, Shepherd: Iavor
by Joachim Breitner 11 Sep '20

11 Sep '20

Dear Committee, this is your secretary speaking: The NoIncomplete pragma has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness… I’ll propose Iavor 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/

1 0