- ghc-steering-committee

a plea for PolyKinds
by Richard Eisenberg 04 Dec '20

04 Dec '20

Hi all, I'd like to make a small plea for PolyKinds. * Haskell is more Haskelly with PolyKinds than without. That is, a key attribute of Haskell is its let-generalization. Yet, oddly, Haskell by default does not generalize its kinds. It should. Here is a motivating example: > data App f a = App (f a) With PolyKinds, App gets the kind (k -> Type) -> k -> Type. Without PolyKinds, GHC has to use defaulting to get (Type -> Type) -> Type -> Type, which might not work at certain use sites. * PolyKinds is backward compatible, except in obscure cases when a PolyKinds module is imported by a NoPolyKinds module. * Supporting NoPolyKinds is difficult within GHC, and I've been waiting for the right time to propose removing support for it. PolyKinds is conceptually *simpler* than NoPolyKinds, as it doesn't require an awkward defaulting step. Vote for PolyKinds! Thanks, Richard

7 10

a plea against ScopedTypeVariables
by Richard Eisenberg 04 Dec '20

04 Dec '20

Hi all, I'd like to make a small plea against ScopedTypeVariables. * First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension. * But I very much dislike the way it brings variables into scope from `forall`s. When I write > f :: forall a. a -> a > f x = (x :: a) I find it very odd that `a` is brought into scope in the body of f. Compare to > f :: (forall a. a -> a) > f x = (x :: a) where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre. * Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively. * I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-499572…, which re-slices this cake. Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future. Thanks, Richard

6 7

#380 GHC2021: Let's deprecate ExistentialQuantification
by Spiwack, Arnaud 04 Dec '20

04 Dec '20

Dear all, ExistentialQuantification is one of the extensions that we are considering adding to GHC2021. ExistentialQuantificaton enables the following syntax: data Dyn = forall a. Typeable a => MkDyn a Has any of us actually used this syntax in recent years? I, personally, only use the equivalent GADT syntax data Dyn where MkDyn :: forall a. Typeable a => a -> Dyn a It’s barely more verbose, and it’s less quirky. Besides, the GADT syntax is there to stay (and GADTSyntax at the very least, is one of these extensions where there seems to be no doubt will be in GHC2021). I’d say there is such a thing as too much syntax. And, in my view, the GADT syntax makes the ExistentialQuantification syntax redundant. I’d much rather we didn’t add it in the defaults so that it can be on its slow path to deprecation. /Arnaud

6 8

CUSKs and StandaloneTypeSignatures
by Alejandro Serrano Mena 04 Dec '20

04 Dec '20

Maybe some part of this discussion got lost. Simon PJ writes: Let's *not* have CUSKs. We are trying to get rid of it... it'd be deeply > strange to "bless" it in GHC2020. > > StandaloneKindSignatures is clearly the Right Thing. I'm sure we'll want > it long term. > > It's a very graceful fit with PolyKinds. > I would really like StandaloneTypeSignatures to be part of the default, and remove CUSKs. Thoughts on this? Is it too early? Regards, Alejandro

4 4

#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