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:
- 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?
- 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
- 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.
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...
-Iavor
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?
On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg
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.
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 https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, 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.
Please review the criteria on the wiki page. Do you agree with what I've put forward?
I've commented on the following extensions:
ApplicativeDo CApiFFI EmptyCase ExplicitNamespaces ForeignFunctionInterface LambdaCase MultiWayIf NamedFieldPuns OverloadedLists OverloadedStrings PatternSynonyms RecordWildCards ScopedTypeVariables StandaloneKindSignatures TupleSections TypeOperators
I have added these new extensions for consideration:
MultiParamTypeClasses ImplicitParams FlexibleContexts FlexibleInstances GeneralizedNewtypeDeriving DeriveDataTypeable DeriveGeneric DefaultSignatures InstanceSigs ConstrainedClassMethods ExplicitForAll DeriveFunctor DeriveTraversable DeriveFoldable PolyKinds RoleAnnotations NegativeLiterals DeriveAnyClass DeriveLift DerivingStrategies EmptyDataDeriving
Looking forward to seeing your thoughts here! Richard