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&amp;data=04%7C01%7Csimonpj%40microsoft.com%
|  >
|  7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%
|  >
|  7C1%7C0%7C637441791891403803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
|  >
|  DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sXj
|  > Sq8Fwla6AysnF9oW5QObfyRGaNcsSVx%2Bh5046Cqg%3D&amp;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&amp;data=04%7
|  C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c5d3e108d8a5eeb045%7C72f
|  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637441791891413801%7CUnknown%7
|  CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
|  CI6Mn0%3D%7C1000&amp;sdata=79QzkT3UBoasQjYNBBu9aBy1Q4e1yVPoLOS08cZgnYg
|  %3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0
|  b75a7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1UtWLiYPCLx
|  P4jNf9K9beUXveTRp8SiG6U%2FFSUK3YXo%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a
|  7949c5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7441791891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=YZypxIrkQlmvj0s
|  MY8tiucfKpZUwQ%2BlUng%2BEKzJsZMA%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C87b4f0b75a7949c
|  5d3e108d8a5eeb045%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374417
|  91891413801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=RkA6zmdd%2BmBPP9yslk
|  Mn5yVfWt58hGNjuhAdzel%2Fi6c%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee