November 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 02 Jul '21

02 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 19 Feb '21

19 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

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

19 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

Please review #370: Syntax for Modifiers, Shepherd: Alejandro
by Joachim Breitner 18 Dec '20

18 Dec '20

Dear Committee, this is your secretary speaking: A syntax for modifiers has been proposed by Richard Eisenberg (this time it’s true) https://github.com/ghc-proposals/ghc-proposals/pull/370 https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=… I’ll propose Alejandro as the shepherd, as he has looked at i t in detail already. 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 20

Unsaturated type families (#242)
by Richard Eisenberg 05 Dec '20

05 Dec '20

Hi committee, Csongor Kiss has proposed -XUnsaturatedTypeFamilies. Proposal: https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/pr… ICFP'19 paper: https://www.microsoft.com/en-us/research/uploads/prod/2019/03/unsaturated-t… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/242 The central idea is to allow type functions (both type families and type synonyms) to appear unsaturated. (Currently, all type functions are required syntactically to be applied to all parameters they are declared with.) This poses a problem for type inference, as detailed in both the proposal and the paper. The key question: if we have (f a ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g is a type function. This proposal thus describes a mechanism to introduce a new flavor of arrow, such that we can identify type functions by their kind. Specifically, we have regular types like Maybe :: Type -> @M Type (where the M stands for "matchable"), but type functions like F :: Type -> @U Type (where the U stands for "unmatchable"). Unmatchable applications can not be decomposed during type inference. Much of the proposal is concerned with backward-compatibility: most users will not want to write @M or @U after each of their arrows, so the proposal describes ways of defaulting this behavior to match (most) programmers' expectations. The proposal also includes matchability polymorphism, the ability to abstract over a matchability parameter. Pros: + This proposal greatly increases the expressiveness of Haskell's type system. + With this proposal, we can finally do proper functional programming in types, rather than just in terms. + This proposal is a key ingredient toward having dependent types, as unsaturated functions are commonplace in terms, and thus should also be supported in types. (Allowing unsaturated functions in types was a key difference between Adam Gundry's proposal for dependent types https://adam.gundry.co.uk/pub/thesis/, which requires a notion of a subset of the type and term languages shared in common, and mine, which makes no distinction between terms and types.) + There is a prototype implementation. + The ideas are backed up by peer-reviewed research. + Despite focusing on type families, this work applies equally to ordinary functions which might be used in types once we have stronger support for dependent types. Cons: - This adds a new dimension of complexity to our kind system, by separating out matchable and unmatchable arrows. - The rules for defaulting appear convenient in practice, but are somewhat arbitrary. - The rules for defaulting care about context -- does an arrow appear in the type of a term or the type of a type? These rules thus go against the spirit of #378, which advocates for not accepting features that distinguish between types and terms. Recommendation: With reservations, I recommend acceptance. I think that the power to use higher-order programming should not be restricted to terms, and allowing unsaturated functions at compile time is necessary in order to have convenient dependent types. However, I am concerned about the extra complexity of matchability. A key open question for me is how much matchability is apparent to users -- even ones using some higher-order type-level programming. If matchability is pervasive, then I would lean against. But my expectation is that matchability fades into the background -- much like levity polymorphism (unless you want it). Open question: What to do about syntax? The proposed syntax is sensible. However, #370 suggests an alternative syntax that might be more forward-thinking. Richard

7 10

GHC2021: DeriveAnyClass
by Alejandro Serrano Mena 04 Dec '20

04 Dec '20

Dear all, I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension. In my case, most of my uses are to derive ToJSON and FromJSON from the Aeson package. I find it very nice to be able to pack all the information about auto-derived instances in a small block, instead of including Eq and Show in the deriving block, and then a few empty instance declarations below. This is definitely mainly a aesthetic reason. The other reason for adoption is that it makes classes such as Eq or Show less “special”, so one does not have to explain to beginners that some classes can be derived in this way, some others in that other way, and so on. So my other reason for inclusion would be a uniformity one. Regards, Alejandro

5 6