[ghc-steering-committee] #380 GHC2021: How to proceed?

Wed Dec 23 00:08:47 UTC 2020

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 at 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 at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 21 December 2020 20:26
> |  To: ghc-steering-committee at 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 at 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 at 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201222/faa35e3f/attachment.html>