<div dir="ltr"><div>Thanks Richard for organizing the wiki page!<br></div><div><br></div><div>I've added some personal notes, mostly about the fact that I think that most people expect "ScopedTypeVariables" to be in a new language standard, even though it breaks some of the rules (which seem like a good general guidance).</div><div><br></div><div>Alejandro<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 1 sept. 2020 a las 20:27, Richard Eisenberg (<<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Sep 1, 2020, at 12:18 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:</div><br><div><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? </div></div></blockquote><div><br></div><div>I agree that the wiki page isn't ideal -- but I don't have a better suggestion, short of, say, a different ticket for each extension (or set of related extensions). My big worry is that email is terrible at this sort of thing. Either everyone quotes every prior person's entire message, or we quote selectively and then easily lose history. Gathering the set of comments pertinent to one extension will be manual and painful.</div><blockquote type="cite"><div dir="ltr"><br><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></blockquote><div><br></div><div>I tend to agree here, both on the evaluation and unsureness of how to capture.</div><br><blockquote type="cite"><div dir="ltr"><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></blockquote><div><br></div><div>As I said above, I think email is a poor place to do this, because we will end up having to pore through the email chain to recreate decisions/rationale for each extension. The wiki is in my opinion a less-poor place to do this. Maybe there is a good place to have the discussion -- that would be great.</div><br><blockquote type="cite"><div dir="ltr"><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></blockquote><div><br></div><div>I was reacting to Eric's concern about FFI. I've updated the wiki to say that FFI is part of Haskell2010. I agree that we should be a superset of extensions.</div><div><br></div><div>Richard</div><br><blockquote type="cite"><div dir="ltr"><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" target="_blank">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>
</blockquote></div><br></div>_______________________________________________<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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>