<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
I would be slightly sad to see ViewPatterns go in, for two reasons: (1) PatternSynonyms covers some of the use cases but by abstracting over data constructors, which doesn't require clients to adopt a non-idiomatic pattern matching style, and (2) for the rest
of the use cases, IMO this design would be better: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fview-patterns-alternative&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937668628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2FfeyRdjkJ17TtX2Ck9dP9MBrx%2BRMZxtTXoVKOLdShA%3D&reserved=0">
https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternative</a><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I too much prefer this view-patterns-alternative rendering of view patterns. I suppose that someone should write a GHC proposal. But there would be some pain in switching from the existing view
patterns to the new one.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
<b>On Behalf Of </b>Simon Marlow<br>
<b>Sent:</b> 03 December 2020 11:26<br>
<b>To:</b> Joachim Breitner <mail@joachim-breitner.de><br>
<b>Cc:</b> ghc-steering-committee <ghc-steering-committee@haskell.org><br>
<b>Subject:</b> Re: [ghc-steering-committee] #380 GHC2021: Current status<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I agree with Simon that we must have GADTs!<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I would be slightly sad to see ViewPatterns go in, for two reasons: (1) PatternSynonyms covers some of the use cases but by abstracting over data constructors, which doesn't require clients to adopt a non-idiomatic pattern matching style, and (2) for the rest
of the use cases, IMO this design would be better: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fview-patterns-alternative&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937668628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2FfeyRdjkJ17TtX2Ck9dP9MBrx%2BRMZxtTXoVKOLdShA%3D&reserved=0">
https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns-alternative</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Simon<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Thu, 3 Dec 2020 at 09:31, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Dear Committee,<br>
<br>
<br>
we have 9 votes in. Dear Cale and Eric, can we have your votes please?<br>
<br>
As always, the table<br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937678622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ph5AXJy8XnPZYxUzNly7ZlNjyHM0uVpNCud%2BqFxXk%2Fk%3D&reserved=0" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data</a><br>
has the current data.<br>
<br>
We had the most discussion so far about:<br>
<br>
* The innnocence of PostfixOperators<br>
* The effect of UnicodeSyntax on error messages<br>
* Whether InstanceSigs is a good design<br>
* Whether OverloadedString is harmless enough.<br>
<br>
I see that three is less clear signal on odd extensions that are<br>
obsolete, on by default, implied by others etc. That’s probably fine<br>
and no need to worry; some of them will be resolved by virtue of being<br>
implied by others. We can also sanity-check the final result, and<br>
include all implied ones in the final design.<br>
<br>
So where do we stand?<br>
<br>
Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go<br>
in no matter how Cale and Eric vote:<br>
<br>
BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable,<br>
DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift,<br>
DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving,<br>
ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax,<br>
HexFloatLiterals, ImportQualifiedPost, KindSignatures,<br>
MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores,<br>
StandaloneDeriving, ViewPatterns<br>
<br>
The following have 6 or 7 votes, i.e. they’d go in if we extrapolate<br>
from the current votes:<br>
<br>
ConstrainedClassMethods, DerivingStrategies,<br>
ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs,<br>
NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards,<br>
ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies,<br>
TypeOperators, TypeSynonymInstances<br>
<br>
These extensions are short one vote:<br>
<br>
DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds<br>
<br>
<br>
<br>
So how sad would we all be? This is the sadness report for each<br>
committee member, showing the symmetric difference between their ballot<br>
and the (extrapolated) result.<br>
<br>
<br>
alejandro<br>
would miss:<br>
DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring,<br>
NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses,<br>
NumDecimals, OverloadedLists, OverloadedStrings, PolyKinds,<br>
StandaloneKindSignatures<br>
doesn’t want:<br>
RankNTypes<br>
<br>
arnaud<br>
would miss:<br>
Arrows, ExplicitNamespaces, ForeignFunctionInterface,<br>
FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds,<br>
PartialTypeSignatures, StarIsType, TypeFamilyDependencies<br>
doesn’t want:<br>
ExistentialQuantification, ImportQualifiedPost, InstanceSigs,<br>
NamedFieldPuns, RankNTypes, RecordWildCards, ScopedTypeVariables,<br>
TupleSections, TypeSynonymInstances<br>
<br>
iavor<br>
would miss:<br>
BlockArguments, MultiWayIf, NoMonomorphismRestriction,<br>
NullaryTypeClasses, OverloadedStrings, ParallelListComp, RecursiveDo<br>
doesn’t want:<br>
ConstrainedClassMethods, ConstraintKinds, DeriveFoldable,<br>
DeriveFunctor, DeriveTraversable, DerivingStrategies, EmptyCase,<br>
GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures,<br>
NegativeLiterals, PostfixOperators, TupleSections, TypeApplications,<br>
TypeFamilies, TypeOperators<br>
<br>
joachim<br>
would miss:<br>
DataKinds, DerivingVia, ForeignFunctionInterface, GADTs, LambdaCase,<br>
MonoLocalBinds, NamedWildCards, NondecreasingIndentation,<br>
RoleAnnotations, StarIsType, UnicodeSyntax, UnliftedFFITypes,<br>
UnliftedNewtypes<br>
doesn’t want:<br>
ConstrainedClassMethods, ScopedTypeVariables, TypeSynonymInstances<br>
<br>
richard<br>
would miss:<br>
BlockArguments, DefaultSignatures, DerivingVia,<br>
DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation,<br>
NamedWildCards, NumDecimals, ParallelListComp, PolyKinds,<br>
RoleAnnotations, StandaloneKindSignatures, TemplateHaskellQuotes,<br>
UnicodeSyntax, UnliftedNewtypes<br>
doesn’t want:<br>
NegativeLiterals, RecordWildCards, ScopedTypeVariables, TypeFamilies<br>
<br>
simonm<br>
would miss:<br>
DataKinds, DefaultSignatures, ForeignFunctionInterface, GADTs,<br>
LambdaCase, LiberalTypeSynonyms, MonoLocalBinds, MultiWayIf,<br>
NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals,<br>
OverloadedStrings, PatternSynonyms, PolyKinds, UnicodeSyntax<br>
doesn’t want:<br>
DeriveLift, DerivingStrategies, NumericUnderscores, TypeApplications,<br>
TypeOperators, ViewPatterns<br>
<br>
spj<br>
would miss:<br>
MonoLocalBinds, NoMonomorphismRestriction, NullaryTypeClasses,<br>
OverloadedLists, OverloadedStrings, ParallelListComp, PolyKinds,<br>
RecursiveDo, RoleAnnotations, StandaloneKindSignatures, StarIsType<br>
doesn’t want:<br>
DerivingStrategies, GeneralisedNewtypeDeriving, NegativeLiterals,<br>
RecordWildCards, TupleSections, TypeFamilies<br>
<br>
tom<br>
would miss:<br>
BlockArguments, DataKinds, DefaultSignatures, DerivingVia,<br>
DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces,<br>
FunctionalDependencies, LambdaCase, LexicalNegation,<br>
LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards,<br>
NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp,<br>
PolyKinds, QuasiQuotes, RoleAnnotations, StandaloneKindSignatures,<br>
TemplateHaskell, TemplateHaskellQuotes, TypeFamilyDependencies,<br>
UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes<br>
doesn’t want:<br>
none!<br>
<br>
vitaly<br>
would miss:<br>
DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring,<br>
StarIsType<br>
doesn’t want:<br>
ConstrainedClassMethods, ExistentialQuantification, PostfixOperators<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937688618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SVEz3KOcsP0oBsVAuh08hXIKrnVlQQJvHaqddyv5GnI%3D&reserved=0" target="_blank">
http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="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%7C642621d2c8cc476d91a908d8977e493f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637425915937688618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z7%2FudmXrboJ9RKKn%2FAXDeknKC0EohWMY1hrzYUYuhJw%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>