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
| 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
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