[ghc-steering-committee] GHC 2020

[Alejandro Serrano Mena]

Thanks Richard for organizing the wiki page!

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).

Alejandro

El mar., 1 sept. 2020 a las 20:27, Richard Eisenberg (<rae at richarde.dev>)
escribió:

>
>
> On Sep 1, 2020, at 12:18 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Thanks for doing this Richard.   I wonder if there might be a different
> way to organize this, that is more suitable for discussion?
>
>
> 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.
>
>
>    - 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.
>
>
> I tend to agree here, both on the evaluation and unsureness of how to
> capture.
>
>
> 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...
>
>
> 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.
>
>
> -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?
>
>
> 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.
>
> Richard
>
>
>
>
>
>
>
> 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
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200901/ca028325/attachment.html>