<div dir="ltr">Thanks for doing this Richard.   I wonder if there might be a different way to organize this, that is more suitable for discussion?   I just had a look at the page, and here are some issue I felt:<div>   - The page is already very long, and it barely has any comments.   I wonder if it might make sense to have one page per extension, instead?  Or at least a separate page for a group of related extensions?</div><div>   - Having a discussion on the wiki is tricky, and maybe before we do that and involve the rest of the community, we could practice among ourselves, at least until we figure out, for example, what might be suitable criteria</div><div>   - When I evaluate the extensions, I do apply some criterias, but my decisions are often not as binary as "this fits" or "this not", but rather more along the lines of "this would make this a little better", "while this might make things a little worse", and "if this was on, I might have to watch out for X,Y,Z, is that a problem?".   I am not sure how to capture this though.</div><div><br></div><div>So, I think my preference would be to have some discussion on the mailing list, or maybe we could even have a video chat with interested folks on specific topics, rather than trying to do everything on the wiki straight away...</div><div><br></div><div>-Iavor</div><div>PS:  By the way, the FFI is part of Haskell2020,  but on the wiki Richard marked it as not qualifying under his criteria 5.  I would expect GHC 202X to be a super-set of the language standard, or do you think we should be also removing things?</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A fun way to start the fall. (Today is my daughter's first day of "school". This defines the beginning of fall.) Thanks, Iavor, for kicking this off.<br>
<br>
I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created <a href="https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020</a>, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.<br>
<br>
Please review the criteria on the wiki page. Do you agree with what I've put forward?<br>
<br>
I've commented on the following extensions:<br>
<br>
ApplicativeDo<br>
CApiFFI<br>
EmptyCase<br>
ExplicitNamespaces<br>
ForeignFunctionInterface<br>
LambdaCase<br>
MultiWayIf<br>
NamedFieldPuns<br>
OverloadedLists<br>
OverloadedStrings<br>
PatternSynonyms<br>
RecordWildCards<br>
ScopedTypeVariables<br>
StandaloneKindSignatures<br>
TupleSections<br>
TypeOperators<br>
<br>
I have added these new extensions for consideration:<br>
<br>
MultiParamTypeClasses<br>
ImplicitParams<br>
FlexibleContexts<br>
FlexibleInstances<br>
GeneralizedNewtypeDeriving<br>
DeriveDataTypeable<br>
DeriveGeneric<br>
DefaultSignatures<br>
InstanceSigs<br>
ConstrainedClassMethods<br>
ExplicitForAll<br>
DeriveFunctor<br>
DeriveTraversable<br>
DeriveFoldable<br>
PolyKinds<br>
RoleAnnotations<br>
NegativeLiterals<br>
DeriveAnyClass<br>
DeriveLift<br>
DerivingStrategies<br>
EmptyDataDeriving<br>
<br>
Looking forward to seeing your thoughts here!<br>
Richard</blockquote></div>