- ghc-steering-committee

List archive failure
by David Feuer 09 Oct '20

09 Oct '20

There was a serious problem on haskell.org leading to a failure to archive several days of mailing list messages. As I am not subscribed to this list, I would appreciate if someone could let me know what, if any, messages have been sent about proposal #367 since the initial request.

2 1

GHC 2020
by Iavor Diatchki 05 Oct '20

05 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

Please review #281: Visible 'forall' in types of terms
by Iavor Diatchki 03 Oct '20

03 Oct '20

Hello, Proposal #281 is ready for review by the committee. My recommendation is to accept it, I've written a summary of my understanding to the proposal and my recommendation on the GitHub thread, accessible through these links: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… Let the discussion begin! -Iavor

2 1

Please review #283: Local modules, Shepherd: Arnaud
by Joachim Breitner 01 Oct '20

01 Oct '20

Dear Committee, this is your secretary speaking: Local Modules has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… I’ll propose Arnaud as the shepherd. Please note that Richard writes > The main alternative to this proposal is #295. It is probably worth > it for at least the committee shepherd to read #295 in concert with > this current proposal, to see which approach they like more. 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

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 19 Sep '20

19 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

Please review #356: Linear Types arrow, Shepherd: Richard
by Joachim Breitner 10 Sep '20

10 Sep '20

Dear Committee, this is your secretary speaking: A syntax change to the linear types arrow has been proposed by Mathieu Boespflug https://github.com/ghc-proposals/ghc-proposals/pull/356 This is a change to the accepted linear types proposal (so no separate link to a rendered proposal). As usual with amendment PRs, I propose the original shepherd, in this case Richard, as the shepherd. Note that Mathiew has a question for us to answer as part of viewing, see https://github.com/ghc-proposals/ghc-proposals/pull/356#issuecomment-690104… so maybe also propose an answer to that? 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

Attempt at clarifying the template language
by Spiwack, Arnaud 07 Sep '20

07 Sep '20

Dear all, I just wrote a short PR[1] which attempts to clarify the language in the template. Trying to dispel some confusion that seems to frequently arise as to what our expectations are, for proposals. Basically, I tried to announce more clearly the things I believe we find ourselves in need to say to proposal authors often about the purpose of sections. I probably forgot some. So bring in your shepperd experience. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/358

1 1