[ghc-steering-committee] GHC 2020

Iavor Diatchki iavor.diatchki at gmail.com
Tue Sep 1 16:18:49 UTC 2020


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 <rae at richarde.dev> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200901/1eeda48f/attachment.html>


More information about the ghc-steering-committee mailing list