- ghc-steering-committee

#380 GHC2021: What's wrong with Functional dependencies
by Spiwack, Arnaud 04 Dec '20

04 Dec '20

Dear all, It seems that a number of us have voted against including FunctionalDependencies and TypeFamilyDependencies. I don't understand why. They are properly guarded by syntax. I don't know any complaint against them FunctionalDependencies, at least, is as standard as it gets (there are functional dependencies all over the mtl). Is it an oversight? Or do some of us really believe that we ought to keep these out, and why? /Arnaud

4 5

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

Please review "Visible 'forall' in types of terms" #281
by Iavor Diatchki 25 Nov '20

25 Nov '20

Hello, Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/00… While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it. I'd be curious about what others think. -Iavor

6 11

Please review #242: Unsaturated type families, Shepherd: Richard Eisenberg
by Joachim Breitner 20 Nov '20

20 Nov '20

Dear Committee, this is your secretary speaking: Unsaturated type families has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/242 https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/pr… I’ll propose Richard Eisenberg 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/

2 1

Prelimary GHC extensions stats
by Joachim Breitner 19 Nov '20

19 Nov '20

Dear Committee, in hopefully anticipation that we can start the GHC2021 process soon, and also given that the Haskell Survey closes today (so we get that data also soon, I guess), I ran a simple analysis against hackage today. I’ll share the data in a proper way when it's time; this is just a preview into what I have in mind. ## Methodology The methodology is: * For each package on hackage, get the latest version * For each such package, try to read out the extensions used in the cabal file and in the modules (This uses https://github.com/kowainik/extensions) * Aggregate these numbers. Out of 12729 packages fetched (4GB), 12025 could be parsed by the extensions library (if anyone cares about the missing ones, please submit fixes to hat library). Only 1116 specify extensions in the cabal file using default- extensions; the rest uses per-file extensions exclusively. This is a relatively low number, so barring bugs in the analysis code, this means that most developers prefer per-module extensions (I am one of those). I extracted three metrics, all represented as percentages: * Proliferation: #(packages using that extensions)/#(packages parsed) (I’ll reserve the word “Popularity” for the data from the poll.) * Innocuousness #(packages enable it in .cabal)/#(packages using default-extensions) A high number here indicates that many developers want this on by default in their project, across all modules. * Aloofness #(packages using this, but _only_ in modules, despite using default-extensions) /#(packages using default-extensions) A high number here indicates that, although a developer was in principle happy with putting extensions into the default-extensions field, they did not include this particular one. I take this as an indication that this extension does _not_ make a great on-by-default extension. (Matching my expectation, TemplateHaskell and CPP make the highest here) Yes, I went overboard with finding fun names to describe the metrics. Happy to take suggestions for more suitable names, maybe from Richard, our master of sophisticated English vocabulary. ## Source I am using this code: https://github.com/nomeata/ghc-proposals-stats/tree/master/ext-stats The are proof that I am very much capable of writing horrible Haskell code that looks like bad python code. If someone (including anyone outside the committee) feels like contributing better code, talk to me! Besides just prettier code, the tool could understand and be smart about implications between extensions, be clever about extensions that are part of the default-language already, and maybe provide nicer reporting. ## Results Eventually I’ll provide a CSV file with all relevant data (hackage stats and poll results), and maybe even upload it on some suitable web service that allows you to explore such a table easily (suggestions?). For now, a preview of the complete output, sorted by Proliferation: Proliferation | Innocousness | | | Aloofness | | | 0% 0% 0% NoMonoLocalBinds 0% 0% 0% NoRebindableSyntax 0% 0% 0% NoMagicHash 0% 1% 0% RelaxedPolyRec 0% 3% 0% DoAndIfThenElse 0% 4% 0% ForeignFunctionInterface 0% 12% 0% PatternGuards 0% 14% 0% EmptyDataDecls 0% 0% 0% ParallelArrays 0% 0% 0% NoForeignFunctionInterface 0% 0% 0% NoDatatypeContexts 0% 0% 0% TransformListComp 0% 0% 0% InterruptibleFFI 0% 1% 0% MonadFailDesugaring 0% 0% 0% NullaryTypeClasses 0% 0% 0% UnboxedSums 0% 0% 0% CApiFFI 0% 0% 0% StaticPointers 0% 0% 0% DerivingStrategies 0% 1% 0% NamedWildCards 0% 0% 0% GHCForeignImportPrim 0% 0% 0% TemplateHaskellQuotes 0% 0% 0% GADTSyntax 0% 0% 0% JavaScriptFFI 0% 0% 0% PostfixOperators 0% 0% 0% DeriveLift 0% 0% 0% NondecreasingIndentation 0% 0% 0% Strict 0% 1% 0% NumDecimals 0% 0% 0% AutoDeriveTypeable 0% 1% 1% StrictData 0% 0% 0% ConstrainedClassMethods 0% 1% 0% DisambiguateRecordFields 0% 2% 0% NegativeLiterals 0% 2% 0% MonadComprehensions 0% 0% 0% UnliftedFFITypes 0% 2% 0% OverloadedLabels 0% 2% 0% BinaryLiterals 0% 2% 0% ApplicativeDo 0% 1% 0% MonoLocalBinds 0% 0% 1% ExplicitNamespaces 0% 1% 1% TypeFamilyDependencies 0% 0% 1% UndecidableSuperClasses 0% 0% 1% RoleAnnotations 1% 0% 1% ExplicitForAll 1% 0% 1% ExtendedDefaultRules 1% 2% 0% RebindableSyntax 1% 3% 0% EmptyCase 1% 3% 0% PartialTypeSignatures 1% 3% 1% DuplicateRecordFields 1% 2% 1% TypeInType 1% 2% 1% ImpredicativeTypes 1% 2% 0% RecursiveDo 1% 0% 2% ImplicitParams 1% 0% 2% OverloadedLists 1% 0% 1% IncoherentInstances 1% 11% 0% LiberalTypeSynonyms 1% 2% 2% AllowAmbiguousTypes 1% 1% 3% DeriveAnyClass 1% 10% 0% ParallelListComp 2% 2% 1% PackageImports 2% 6% 1% InstanceSigs 2% 11% 0% Arrows 2% 6% 0% UnicodeSyntax 2% 4% 2% PatternSynonyms 2% 6% 3% TypeApplications 2% 0% 2% OverlappingInstances 3% 9% 1% UnboxedTuples 3% 15% 1% MultiWayIf 3% 6% 3% NamedFieldPuns 4% 16% 2% DeriveFoldable 4% 7% 3% PolyKinds 4% 16% 2% DeriveTraversable 4% 10% 3% MagicHash 4% 13% 3% NoMonomorphismRestriction 4% 18% 4% DefaultSignatures 6% 8% 5% ViewPatterns 6% 10% 4% KindSignatures 6% 15% 6% QuasiQuotes 6% 3% 6% ExistentialQuantification 7% 30% 2% NoImplicitPrelude 7% 25% 6% ConstraintKinds 8% 23% 6% DeriveFunctor 8% 22% 6% FunctionalDependencies 9% 24% 6% StandaloneDeriving 9% 24% 6% TupleSections 10% 25% 6% DataKinds 10% 6% 8% TypeSynonymInstances 11% 28% 4% LambdaCase 11% 24% 7% GADTs 12% 27% 5% TypeOperators 12% 6% 15% UndecidableInstances 12% 20% 7% BangPatterns 14% 27% 10% DeriveGeneric 15% 27% 8% RecordWildCards 17% 21% 16% TemplateHaskell 17% 29% 14% GeneralizedNewtypeDeriving 19% 29% 12% RankNTypes 20% 26% 8% DeriveDataTypeable 20% 31% 11% TypeFamilies 21% 34% 11% MultiParamTypeClasses 22% 11% 18% CPP 25% 37% 13% ScopedTypeVariables 26% 42% 14% FlexibleContexts 31% 43% 16% FlexibleInstances 34% 53% 10% OverloadedStrings Enjoy! Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 6

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Delimited continuation primops (#313)
by Simon Peyton Jones 17 Nov '20

17 Nov '20

Simon, Charles is right. You were appointed shepherd on 12 Sept, and our guidelines are that the shepherd should make a recommendation within a fortnight, and guide the committee to a conclusion. I guess this fell off your radar. Simon From: Charles Strahan <notifications(a)github.com> Sent: 13 November 2020 18:36 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Mention <mention(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] Delimited continuation primops (#313) Is this awaiting @simonmar<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>'s action, or is this pending @lexi-lambda<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>'s response to @simonpj<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> (or something else)? ________________________________ I fear unintentionally spamming this list, but I find that the next step isn't obvious to me, so I figured there might be some value for all involved parties in raising the question. While I'm here: I'm very excited about this work! 🙂 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.

2 1

Type applications in patterns
by Simon Peyton Jones 17 Nov '20

17 Nov '20

Dear Steering Committee You may remember that we approved the Type Applications in Patterns<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0126-t…> proposal, some time ago. Cale has been implementing it (see ticket 11350<https://gitlab.haskell.org/ghc/ghc/-/issues/11350> and MR 2464<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2464>). It's nearly done. But in doing so, one design choice came up that we did not discuss much, and I'd like to consult you. Consider first the existing pattern-signature mechanism (not the new feature): data T a where MkT :: forall a b. a -> b -> T a f1 :: forall p. T [p] -> blah f1 (MkT (x :: a) pi) = blah f2 :: forall p. T [p] -> blah f2 (MkT (x :: p) pi) = blah In f1, the pattern (x :: a) brings 'a' into scope, binding it to the type [p]. But in f2, since p is already in scope, the pattern (x :: p) does not bring anything new into scope. Instead it requires that x have type p, but actually it has type [p], so f2 is rejected. Notice that a pattern signature brings a new variable into scope only if it isn't already in scope. Notice how this differs from the treatment of term variables; the 'pi' in the pattern brings 'pi' into scope unconditionally, shadowing the existing 'pi' (from the Prelude). OK, now let's look at the new feature. Consider g1 :: forall p. T [p] -> blah g1 (MkT @a x y) = blah g2 :: forall p. T [p] -> blah g2 (MkT @p x pi) = blah Question: should the variables free in these type arguments be treated like pattern signatures, or like term variables? 1. Like pattern signatures. In this design, in g1, 'a' is not in scope, so this brings it into scope, bound to [p]. But in g2, 'p' is in scope, so this is rejected (because MkT is instantiated at [p] not p. 2. Like term variables. In this design, all the variables free in type patterns are fresh, and brought into scope. In g2, a new 'p' is brought into scope, shadowing the existing 'p'; indeed the new 'p' is bound to [old_p]. The original paper, and hence the accepted proposal, adopts (A). But Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify scoping for type applications in pattens<https://github.com/ghc-proposals/ghc-proposals/pull/291> to advocate this change. (The proposal is not easy to understand, but advocating (B) is its payload. This is not a terribly big deal, but it would be good to settle it. The right place to have debate is on Proposal 291<https://github.com/ghc-proposals/ghc-proposals/pull/291>. This email is just to alert you to it, and ask for your opinions. Simon

4 3

We have a nudger!
by Simon Peyton Jones 16 Nov '20

16 Nov '20

Friends Our GHC proposals process says * A shepherd will make a recommendation within 2 weeks * Committee will make a decision with 4 weeks after that But we sometimes drop the ball and we have no recovery mechanism, which isn't really fair on authors. At our ICFP meeting we decided to appoint a "Nudger" to watch the timetable (weekly perhaps) give the shepherds a polite nudge. If successive nudges don't work (e.g. perhaps a committee member has been overtaken by an emergency) then s/he can alert the Secretary to appoint a new shepherd. I'm happy to say that Tom Harding has agreed to act as our Nudger, for six-month term. Thank you Tom! You may want to check with Joachim about exactly what's in flight. Shepherds: note that it's fine to have an active dialogue with the author about content, before making your recommendation. That might take longer than 2 weeks, but make sure the author knows that is what you are doing. Thanks Tom! Simon

2 1

Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding
by Joachim Breitner 16 Nov '20

16 Nov '20

Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/pro… I’ll propose Tom Harding 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

Re: [ghc-steering-committee] GHC 20xx process
by Richard Eisenberg 16 Nov '20

16 Nov '20

This is an effective argument; you've changed my mind. I'm now in favor of Joachim's simpler process. Thanks for writing this all out! Richard > On Nov 6, 2020, at 4:02 AM, Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > Hi, > > we may be repeating points here, but I am still strongly leaning > towards a more lightweight process. At least initially, so that we can > iterate towards something more heavy in later rounds, rather than going > the other way (in general easier to add process than remove process). > > You mention that discussions will pop us elsewhere. I don’t find that > bad! We committee members are here to represent the community, and I > expect that enough of us are “in touch” with the community to pick up > useful signal, even if it happens on reddit or twitter, and will carry > that into their votes and rationales. There will be discussion in > reddit and twitter and mailing lists _anyways_! > > What I want to avoid is sending a signal to the community to say “we > are going to do about 100 individual decisions soon and, by the way, we > really encourage you to comment on all of them (why else would we give > you the explicit space). > I’d rather send the signal “we are going to > make 100 individual decisions, here you can follow the process, and if > you _really_ think we are missing something, this PR is where your > input is welcome.” > > Also, speaking as the secretary, managing a separate repo and expecting > all of us to following many different issues seems out of proportion of > what we want to achieve here. > > > Maybe popping up a bit: It’s worth noting that the first round will be > very different than all the subsequent roads. In the first round we > have a _large_ number of low-hanging fruit to pluck. In fact, it’s so > many of them, that I expect we simply don't have the capacity to do > very careful deliberation of each of them. > > This implies that the first round, we should aim _low_, and be very > conservative, knowing that the following rounds we have less to > discuss, and can then be more careful discussions about those > extensions that need those discussions. > > So what does this mean for community involvement? There are two cases > for a given extension FooBar: > > * Our vote initially doesn’t include FooBar. > > Yes, for almost every extension there will be a few people who think > that it should be in. This is not very useful signal! > > In fact, in this case, we’d likely say “thanks for your input! For > the first round, we are going to be conservative, and we didn’t > include FooBar for now. But maybe next year!” > > I don’t think we or the community benefits from first making space > for that discussion, to then only cut it off politely. > > * Our vote initially includes FooBar. > > Then, maybe, someone has a good argument why FooBar is actually less > harmless than we have thought. That _is_ useful signal! > > But I expect this to be rare: It only applies to the already > filtered list of extensions, not all 100, and if we do our job good, > only a few cases like this arise. Thus a normal discussion on the PR > on our normal repository, just like with any other proposal, > suffices to get that signal. > > I am making a few assumptions here about how we want to run this > (aiming for a conservative list of extensions in the first round, and > trying to be efficient with our own resources), and with these > assumption the more lightweight process seems more appropriate to begin > with. > > One can of course disagree with these assumption (e.g. aiming for a > very elaborate process to pick a very “complete” set right away), and > then deduce that Alternative 2 is needed. > > > 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

6 8