Hello, here is another update to my votes. The change is mostly to eliminate all `maybe` with a concrete `yes` or `no`. Module System ============= ImportQualifiedPost: yes PackageImports: no NoImplicitPrelude: no Notation ======== BlockArguments: yes MultiWayIf: yes LambdaCase: no BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: yes OverloadedStrings: yes OverloadedLists: no OverloadedLabels: no EmptyCase: yes PostfixOperators: yes LexicalNegation: yes UnicodeSyntax: yes NegativeLiterals: no TupleSections: yes ImplicitParams: no ParallelListComp: yes RecursiveDo: yes TransformListComp: no Arrows: no ApplicativeDo: yes QualifiedDo: no MonadComprehensions: no NondecreasingIndentation: no RebindableSyntax: no ExplicitNamespaces: no Data Types ========== DatatypeContexts: no ExistentialQuantification: yes EmptyDataDecls: yes RoleAnnotations: no StrictData: no GADTSyntax: yes GADTs: no Patterns and Guards =================== BangPatterns: yes ViewPatterns: no PatternSynonyms: no NoPatternGuards: no NPlusKPatterns: no Records ======= NamedFieldPuns: yes RecordWildCards: yes DisambiguateRecordFields: no DuplicateRecordFields: no NoTraditionalRecordSyntax: no Deriving ======= DeriveGeneric: yes DeriveLift: yes DeriveDataTypeable: yes EmptyDataDeriving: yes StandaloneDeriving: yes DeriveFunctor: yes DeriveFoldable: yes DeriveTraversable: yes DerivingStrategies: no DerivingVia: no GeneralisedNewtypeDeriving: no DeriveAnyClass: no Class System ============ MultiParamTypeClasses: yes NullaryTypeClasses: yes ConstraintKinds: yes TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes ConstrainedClassMethods: yes DefaultSignatures: no InstanceSigs: yes ExtendedDefaultRules: no FunctionalDependencies: no QuantifiedConstraints: no UndecidableInstances: no IncoherentInstances: no UndecidableSuperClasses: no OverlappingInstances: no Types ===== RankNTypes: yes StandaloneKindSignatures: yes KindSignatures: yes LiberalTypeSynonyms: no ScopedTypeVariables: yes ExplicitForAll: yes AllowAmbiguousTypes: no ImpredicativeTypes: no MonoLocalBinds: no NoMonomorphismRestriction: yes PartialTypeSignatures: no NamedWildCards: no LinearTypes: no TypeApplications: no PolyKinds: no TypeOperators: no StarIsType: yes TypeFamilies: no TypeFamilyDependencies: no DataKinds: no FFI === ForeignFunctionInterface: yes CApiFFI: yes GHCForeignImportPrim: no InterruptibleFFI: no UnliftedFFITypes: no StaticPointers: no Low Level ========= UnboxedSums: no UnboxedTuples: no MagicHash: no UnliftedNewtypes: yes Macros ====== CPP: no TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no Other ===== Unsafe: no Safe: no Trustworthy: no Strict: no Obsolete/Deprecated =================== CUSKs: no TypeInType: no MonadFailDesugaring: yes On Tue, Dec 22, 2020 at 2:06 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:
| It's accurate, but checking was was quite tedious, hard to automate, | and hence. I guess I can keep it up to date as new votes come in, so | that might be fine.
Thanks. The crucial thing is that it's grouped in a logical way, so it's possible to address the question "does this make a coherent language design".
Simon
| -----Original Message----- | From: ghc-steering-committee <ghc-steering-committee- | bounces@haskell.org> On Behalf Of Joachim Breitner | Sent: 21 December 2020 20:26 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] #380 GHC2021: How to proceed? | | Hi, | | > Then we should allow a fortnight, say to 18 Jan (my birthday). | | if Simon says that his birthday wish from us is a well-thought | through, conclusively discussed, shiny and nice GHC2021, then of | course we will make it so :-) | | Am Montag, den 21.12.2020, 19:50 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > As you know, I have found it extremely difficult to make sense of a | table with more than 100 rows. I think we need a global summary and I | have prepared one here: | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs | > | .google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA | > | Na8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com% | > | 7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47% | > | 7C1%7C0%7C637441791891403803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM | > | DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sXj | > Sq8Fwla6AysnF9oW5QObfyRGaNcsSVx%2Bh5046Cqg%3D&reserved=0 | > | > Is it accurate? I have not cross-checked against the vote table in | the last week or two. You all have edit permission for this document. | | It's accurate, but checking was was quite tedious, hard to automate, | and hence. I guess I can keep it up to date as new votes come in, so | that might be fine. | | Or I scrape the categorization of extensions from the docs ( | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc. | gitlab.haskell.org%2Fghc%2Fdoc%2Fusers_guide%2Fexts.html&data=04%7 | C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637441791891413801%7CUnknown%7 | CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV | CI6Mn0%3D%7C1000&sdata=79QzkT3UBoasQjYNBBu9aBy1Q4e1yVPoLOS08cZgnYg | %3D&reserved=0 nicely groups them by topic), and generate this | view automatically from the data, as part of | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0 | b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1UtWLiYPCLx | P4jNf9K9beUXveTRp8SiG6U%2FFSUK3YXo%3D&reserved=0 | | Would that help? | | > * Everyone: check that the union of "in" and "barely in" makes sense | as a | > coherent language design | > * Everyone: make the case for any changes. But only for borderline | cases. No | > point in arguing for something that is nowhere near the | borderline, unless | > you really think everyone has misunderstood | > | > I think the period from now to 4 Jan doesn't count. Then we should | > allow a fortnight, say to 18 Jan (my birthday). | > | > Is that acceptable? | | Very much so, I think, thanks. | | Also remember to go through your maybes. (If both SPJ and Arnaud turn | their "maybe" about UnicodeSyntax to yes it makes it in ;-)) | | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a | 7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YZypxIrkQlmvj0s | MY8tiucfKpZUwQ%2BlUng%2BEKzJsZMA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c | 5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374417 | 91891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RkA6zmdd%2BmBPP9yslk | Mn5yVfWt58hGNjuhAdzel%2Fi6c%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee