From rae at richarde.dev  Mon May  3 15:40:43 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 3 May 2021 15:40:43 +0000
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <010f01790060f099-e40f648d-47b3-4053-a1a5-9200e2d338f3-000000@us-east-2.amazonses.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
 <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
 <CAHnFXOuFYyzvmsx7pEAWce-6ViZLW4dxJew0Zhj3XxP5o1po=A@mail.gmail.com>
 <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com>
 <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com>
 <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com>
 <CAH6fHQk5TvLDBDAcOZ=yt2R3hUWZyKQOmdF9LCTLYHEEteDXVw@mail.gmail.com>
 <0A7BA6AB-BDF3-41E3-8195-4CA89CB160DC@gmail.com>
 <010f01790060f099-e40f648d-47b3-4053-a1a5-9200e2d338f3-000000@us-east-2.amazonses.com>
Message-ID: <010f017932e38a6b-120ec45b-21cc-40ec-ae43-b3ba4d89140c-000000@us-east-2.amazonses.com>

Well, I said I would accept by now, but I would like more participation here before I feel comfortable doing so.

Specifically:
* Alejandro and Arnaud have made utterances against this proposal, however neither said "I'm against" or something equivalent.
* Simon PJ just rubber-stamped my recommendation
* Joachim gave a weak approval (as have I).

Do others have an opinion? Alejandro & Arnaud, have either of you changed camps? It would feel better if this were approved by something resembling a majority of the committee, instead of just my recommendation with Joachim's mild concurrence and SPJ's rubber stamp.

Thanks,
Richard

> On Apr 23, 2021, at 4:17 PM, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> To my deep surprise, the following program is accepted:
> 
>> {-# LANGUAGE GADTSyntax, ExistentialQuantification #-}
>> 
>> module Bug where
>> 
>> data G a where
>>  MkG :: a -> G Int
> 
> but the following additional definition is rejected:
> 
>> foo :: G a -> a
>> foo (MkG _) = 5
> 
> Adding -XTypeFamilies fixes that last piece, though.
> 
> Looking through the source code, GADTs implies GADTSyntax and MonoLocalBinds, either GADTs or ExistentialQuantification allows the declaration of existential variables or a refined return type, either GADTs or TypeFamilies allows the use of the `~` syntax, and either GADTs or TypeFamilies allows pattern-matching on a constructor with an equality in its context. So, GADTSyntax, ExistentialQuantification, and TypeFamilies together imply all the functionality of GADTs.
> 
> This is all very strange, though, and should probably be tidied up. Not in this proposal though.
> 
> Richard
> 
>> On Apr 23, 2021, at 2:54 PM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com> wrote:
>> 
>> While the use of (~) itself no longer requires -XGADTs, the usual desugaring of GADTs still does. So this will require the extension:
>> 
>> data G a where
>> MkG :: G Int
>> 
>> even though this will not:
>> 
>> data T a where
>> MkT :: (a~Int) => T a
>> 
>> Perhaps that is what you meant by ‘vacuous’, but I wouldn’t go as far as to say that -XGADTs becomes implied by -XGADTSyntax and -XExistentialTypes.
>> 
>> - Vlad
>> 
>>> On 22 Apr 2021, at 12:25, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>>> 
>>> I'm still not sure what problem this proposal solves. The proposal alludes to some code simplification but doesn't give me a good idea of how much simpler this would make the code.
>>> 
>>> Also note that -XGADT becomes mostly vacuous with this proposal: -XGADTSyntax + -XExistentialTypes imply GADTs (both are in -XGHC2021). Not that I mind, really, I actually probably prefer it this way. But it's worthy of notice.
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Tue May  4 07:41:56 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 May 2021 09:41:56 +0200
Subject: [ghc-steering-committee] Please review #392: Clarify modifiers
 design principle, Shepherd: Alejandro
Message-ID: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>

Dear Committe,

Clarify modifiers design principle
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/392

This is an amendmend to #370, see the PR description for links to diffs
etc.

I propose Alejandro as the shepherd, as he shepherded #370 before.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Tue May  4 12:01:59 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 4 May 2021 14:01:59 +0200
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <010f017932e38a6b-120ec45b-21cc-40ec-ae43-b3ba4d89140c-000000@us-east-2.amazonses.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
 <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
 <CAHnFXOuFYyzvmsx7pEAWce-6ViZLW4dxJew0Zhj3XxP5o1po=A@mail.gmail.com>
 <4F0B1081-DFAF-42CE-A3CF-F00BEFBF44B9@gmail.com>
 <010f01788eb9bfda-8728f034-a0f5-43f2-ac79-69c4e836a571-000000@us-east-2.amazonses.com>
 <010f0178f757c6b8-f8c61c40-cf70-439a-9357-2ff90e9fa0e9-000000@us-east-2.amazonses.com>
 <CAH6fHQk5TvLDBDAcOZ=yt2R3hUWZyKQOmdF9LCTLYHEEteDXVw@mail.gmail.com>
 <0A7BA6AB-BDF3-41E3-8195-4CA89CB160DC@gmail.com>
 <010f01790060f099-e40f648d-47b3-4053-a1a5-9200e2d338f3-000000@us-east-2.amazonses.com>
 <010f017932e38a6b-120ec45b-21cc-40ec-ae43-b3ba4d89140c-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=Eqve2dxPRBNBObovMYpBTqRt-cG+zbXRbfroHL1=nCw@mail.gmail.com>

I've asked a question about the anticipated code simplification but didn't
get a reply. So my opinion has not shifted. But it's not something that I
have strong opinions on either way.

On Mon, May 3, 2021 at 5:41 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Well, I said I would accept by now, but I would like more participation
> here before I feel comfortable doing so.
>
> Specifically:
> * Alejandro and Arnaud have made utterances against this proposal, however
> neither said "I'm against" or something equivalent.
> * Simon PJ just rubber-stamped my recommendation
> * Joachim gave a weak approval (as have I).
>
> Do others have an opinion? Alejandro & Arnaud, have either of you changed
> camps? It would feel better if this were approved by something resembling a
> majority of the committee, instead of just my recommendation with Joachim's
> mild concurrence and SPJ's rubber stamp.
>
> Thanks,
> Richard
>
> > On Apr 23, 2021, at 4:17 PM, Richard Eisenberg <rae at richarde.dev> wrote:
> >
> > To my deep surprise, the following program is accepted:
> >
> >> {-# LANGUAGE GADTSyntax, ExistentialQuantification #-}
> >>
> >> module Bug where
> >>
> >> data G a where
> >>  MkG :: a -> G Int
> >
> > but the following additional definition is rejected:
> >
> >> foo :: G a -> a
> >> foo (MkG _) = 5
> >
> > Adding -XTypeFamilies fixes that last piece, though.
> >
> > Looking through the source code, GADTs implies GADTSyntax and
> MonoLocalBinds, either GADTs or ExistentialQuantification allows the
> declaration of existential variables or a refined return type, either GADTs
> or TypeFamilies allows the use of the `~` syntax, and either GADTs or
> TypeFamilies allows pattern-matching on a constructor with an equality in
> its context. So, GADTSyntax, ExistentialQuantification, and TypeFamilies
> together imply all the functionality of GADTs.
> >
> > This is all very strange, though, and should probably be tidied up. Not
> in this proposal though.
> >
> > Richard
> >
> >> On Apr 23, 2021, at 2:54 PM, Vladislav Zavialov (int-index) <
> vlad.z.4096 at gmail.com> wrote:
> >>
> >> While the use of (~) itself no longer requires -XGADTs, the usual
> desugaring of GADTs still does. So this will require the extension:
> >>
> >> data G a where
> >> MkG :: G Int
> >>
> >> even though this will not:
> >>
> >> data T a where
> >> MkT :: (a~Int) => T a
> >>
> >> Perhaps that is what you meant by ‘vacuous’, but I wouldn’t go as far
> as to say that -XGADTs becomes implied by -XGADTSyntax and
> -XExistentialTypes.
> >>
> >> - Vlad
> >>
> >>> On 22 Apr 2021, at 12:25, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >>>
> >>> I'm still not sure what problem this proposal solves. The proposal
> alludes to some code simplification but doesn't give me a good idea of how
> much simpler this would make the code.
> >>>
> >>> Also note that -XGADT becomes mostly vacuous with this proposal:
> -XGADTSyntax + -XExistentialTypes imply GADTs (both are in -XGHC2021). Not
> that I mind, really, I actually probably prefer it this way. But it's
> worthy of notice.
> >>>
> >>> _______________________________________________
> >>> ghc-steering-committee mailing list
> >>> ghc-steering-committee at haskell.org
> >>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> 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/20210504/cb575840/attachment.html>

From rae at richarde.dev  Tue May  4 12:16:03 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 4 May 2021 12:16:03 +0000
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
 <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
Message-ID: <010f0179374e869e-16249859-ae94-4969-b3e2-7383bf78d62a-000000@us-east-2.amazonses.com>



> On Mar 31, 2021, at 10:29 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Those of us who have been involved in the parts of the compiler that are touched here: do you think this is a worthwhile simplification?

Yes, I think so. Every special widget in the language takes custom support, and this removes one. The implementation of `~` will still be somewhat special, but there's no reason the parsing, etc., needs to be.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210504/211bd02e/attachment.html>

From arnaud.spiwack at tweag.io  Mon May 10 05:57:11 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 10 May 2021 07:57:11 +0200
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <010f0179374e869e-16249859-ae94-4969-b3e2-7383bf78d62a-000000@us-east-2.amazonses.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
 <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
 <010f0179374e869e-16249859-ae94-4969-b3e2-7383bf78d62a-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=HdaZ+C1B+nd1gp5JjeHZZpKxEaeEEoDDvqRCinDfV0A@mail.gmail.com>

It's not a very concrete statement. I'll have to trust you on this.

I guess that if `~` doesn't get special parsing rules then it's an
overridable name. This is good. And everything which can simplify the
parser is welcome. So let me vote: aye.

On Tue, May 4, 2021 at 2:16 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 31, 2021, at 10:29 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> Those of us who have been involved in the parts of the compiler that are
> touched here: do you think this is a worthwhile simplification?
>
>
> Yes, I think so. Every special widget in the language takes custom
> support, and this removes one. The implementation of `~` will still be
> somewhat special, but there's no reason the parsing, etc., needs to be.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210510/75a606e3/attachment.html>

From tomjharding at live.co.uk  Mon May 10 10:06:32 2021
From: tomjharding at live.co.uk (Tom Harding)
Date: Mon, 10 May 2021 10:06:32 +0000
Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma,
 Shepherd: Tom
In-Reply-To: <010f017919aec35b-ee84f52b-5d71-431c-9492-9015dd903c67-000000@us-east-2.amazonses.com>
References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de>
 <AM5PR83MB03534D68AC42D6B6D5FBF342AD479@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHnFXOuRcM1HmZDUmeAYzG4uOG=i05GGh7mMNznO_m3iYR_fYQ@mail.gmail.com>
 <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk>
 <CAH6fHQ=TGvGwcgcGSpmTJ-MdYh0bFN3tNy84iCR-zGQB8Qusaw@mail.gmail.com>
 <010f017919aec35b-ee84f52b-5d71-431c-9492-9015dd903c67-000000@us-east-2.amazonses.com>
Message-ID: <F39CD36C-784A-4A50-B186-8287BE766C2F@live.co.uk>

Hi all,

Sorry for the delay - I’ve been moving house over the last fortnight, so I’ve been falling behind on my duties!
If I take silence to mean “no objections”, it sounds as though everyone with an opinion is in favour of this one; Joachim, are we OK to accept?

Thanks,
Tom

On 28 Apr 2021, at 19:12, Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>> wrote:

I don't personally understand the details behind the motivation, but I trust the people who have supported and will throw my lot in with them.

+1 from me.

On Apr 28, 2021, at 11:08 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:

It occurs to me that this OPAQUE keyword may be useful for vanilla GHC as well. GHC could provide trivial implementation of some primitive functions that it defines (such as the recently discussed `withDict` function) and use the OPAQUE keyword to make sure that it can always substitute this function by its low-level implementation possibly even at the STG level if the primitive doesn't admit a Core implementation.

I don't really have a strong opinion either way, but it sounds reasonable.

On Tue, Apr 27, 2021 at 11:22 AM Tom Harding <tomjharding at live.co.uk<mailto:tomjharding at live.co.uk>> wrote:
Hi all,

I’ve read the proposal: the change is well-motivated, and seems to solve a problem that doesn’t have another pre-existing ergonomic or reliable solution.
Given this, I recommend that we accept. Alejandro and Simon have already given their support; does anyone else have any strong opinions either way?

Thanks,
Tom

On 21 Apr 2021, at 20:54, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

That seems reasonable and with a direct application, so I’m in favor of acceptance.

Alejandro

On 21 Apr 2021 at 11:07:14, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
Tom, I'm in support of this.  It's simple, useful, driven by a real application need, and easy to implement.  (There a small patch that does it already.)

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
|  Sent: 21 April 2021 07:40
|  To: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>>
|  Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma,
|  Shepherd: Tom
|
|  Dear Committe,
|
|  OPAQUE pragma
|  has been proposed by Christiaan Baaij
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com<http://ub.com/>%2Fghc-proposals%2Fghc-
|  proposals%2Fpull%2F415&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C06
|  54777eb2f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637545841499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wm44ph5
|  Int4gqu6JKkedaAKqE0DJOcqjqK3%2BT%2BHEXcA%3D&amp;reserved=0
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com<http://ub.com/>%2Fchristiaanb%2Fghc-
|  proposals%2Fblob%2Fmaster%2Fproposals%2F0000-opaque-
|  pragma.md&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C0654777eb2f74ee
|  ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458
|  41499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MD9R%2FGRTR8j8blj%2F
|  o2cCc6JFpbgPiGakqGkZoSoQkeg%3D&amp;reserved=0
|
|
|  I'll propose Tom as the shepherd.
|
|  Please guide us to a conclusion as outlined in
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
|  ub.com<http://ub.com/>%2Fghc-proposals%2Fghc-proposals%23committee-
|  process&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C0654777eb2f74eeff
|  5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637545841
|  499459221%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
|  LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VEiKysJyP4hRJ3J%2FIAQ0
|  k2t9qm7qhreZF%2FMfA31Ct1k%3D&amp;reserved=0
|
|  Thanks,
|  Joachim
|  --
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
|
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de<http://breitner.de/>%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C0654777eb2
|  f74eeff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7545841499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=zURoYM0rQvnF%2F
|  j0EngntoTDt2cG7aSPEResXA4i6m%2FE%3D&amp;reserved=0
|
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  .haskell.org<http://haskell.org/>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com<http://40microsoft.com/>%7C0654777eb2f74ee
|  ff5df08d904906a19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375458
|  41499469214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=TEQsWPaCoHIvcGy%2FH1
|  te1tmgRGe%2BHeYwhU1FcoZ4TVM%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto: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/20210510/665450ee/attachment-0001.html>

From mail at joachim-breitner.de  Mon May 10 11:27:03 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 10 May 2021 13:27:03 +0200
Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma,
 Shepherd: Tom
In-Reply-To: <F39CD36C-784A-4A50-B186-8287BE766C2F@live.co.uk>
References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de>
 <AM5PR83MB03534D68AC42D6B6D5FBF342AD479@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHnFXOuRcM1HmZDUmeAYzG4uOG=i05GGh7mMNznO_m3iYR_fYQ@mail.gmail.com>
 <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk>
 <CAH6fHQ=TGvGwcgcGSpmTJ-MdYh0bFN3tNy84iCR-zGQB8Qusaw@mail.gmail.com>
 <010f017919aec35b-ee84f52b-5d71-431c-9492-9015dd903c67-000000@us-east-2.amazonses.com>
 <F39CD36C-784A-4A50-B186-8287BE766C2F@live.co.uk>
Message-ID: <9c0a55bc559f006dab55ee073c533bbfad904687.camel@joachim-breitner.de>

Hi,

Am Montag, den 10.05.2021, 10:06 +0000 schrieb Tom Harding:
> Sorry for the delay - I’ve been moving house over the last fortnight, so I’ve been falling behind on my duties!
> If I take silence to mean “no objections”, it sounds as though everyone with an opinion is in favour of this one; Joachim, are we OK to accept?

looks like it. Maybe we can wait until tomorrow for last minute
expressions of opinions (I’m distracted today anyways)

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Mon May 10 16:33:34 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 10 May 2021 16:33:34 +0000
Subject: [ghc-steering-committee] #371: Stop treating ~ magically. Rec:
 weak accept
In-Reply-To: <CAH6fHQ=HdaZ+C1B+nd1gp5JjeHZZpKxEaeEEoDDvqRCinDfV0A@mail.gmail.com>
References: <010f017885c281e2-ddc4c62f-b5e8-4829-bdf2-aab06bbd99f3-000000@us-east-2.amazonses.com>
 <CAH6fHQkzB=CuNWXhWqGJ4UR2zB8HkeFkA7F09iYC9_AVB_gd+Q@mail.gmail.com>
 <010f0179374e869e-16249859-ae94-4969-b3e2-7383bf78d62a-000000@us-east-2.amazonses.com>
 <CAH6fHQ=HdaZ+C1B+nd1gp5JjeHZZpKxEaeEEoDDvqRCinDfV0A@mail.gmail.com>
Message-ID: <010f017957207046-a42bd001-d628-4eb0-8dc5-37a335c15940-000000@us-east-2.amazonses.com>

It sounds like we have enough support here to declare this accepted. I will do so now.

Thanks, all!
Richard

> On May 10, 2021, at 1:57 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> It's not a very concrete statement. I'll have to trust you on this.
> 
> I guess that if `~` doesn't get special parsing rules then it's an overridable name. This is good. And everything which can simplify the parser is welcome. So let me vote: aye.
> 
> On Tue, May 4, 2021 at 2:16 PM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> 
>> On Mar 31, 2021, at 10:29 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>> Those of us who have been involved in the parts of the compiler that are touched here: do you think this is a worthwhile simplification?
> 
> Yes, I think so. Every special widget in the language takes custom support, and this removes one. The implementation of `~` will still be somewhat special, but there's no reason the parsing, etc., needs to be.
> 
> Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210510/5c998762/attachment.html>

From trupill at gmail.com  Tue May 11 08:10:16 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 11 May 2021 08:10:16 +0000
Subject: [ghc-steering-committee] #392: Clarify modifiers design principle
	(recommendation: acceptance)
In-Reply-To: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
Message-ID: <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>

 Dear Committee,
This proposal seems a natural extension of #370, covering some additional
cases (modifiers to classes and other declarations) that we’ve found along
the way. My recommendation is acceptance.

Regards,
Alejandro

On 4 May 2021 at 09:41:56, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committe,
>
> Clarify modifiers design principle
> has been proposed by Richard
> https://github.com/ghc-proposals/ghc-proposals/pull/392
>
> This is an amendmend to #370, see the PR description for links to diffs
> etc.
>
> I propose Alejandro as the shepherd, as he shepherded #370 before.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> --
> --
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20210511/d2772f49/attachment.html>

From arnaud.spiwack at tweag.io  Wed May 12 09:26:54 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 12 May 2021 11:26:54 +0200
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
Message-ID: <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>

I've commented on the PR [
https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189
] the changes on the syntax of lambda expressions are not motivated at all,
I think at the very least there should be a discussion in the Alternatives
section.

But mostly, I'm worried about the implications/interactions that these
changes have with linear types.

(I'll be off for the rest of the week starting tonight, so I'll be back on
this conversation on Monday, most likely)

On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> Dear Committee,
> This proposal seems a natural extension of #370, covering some additional
> cases (modifiers to classes and other declarations) that we’ve found along
> the way. My recommendation is acceptance.
>
> Regards,
> Alejandro
>
> On 4 May 2021 at 09:41:56, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committe,
>>
>> Clarify modifiers design principle
>> has been proposed by Richard
>> https://github.com/ghc-proposals/ghc-proposals/pull/392
>>
>> This is an amendmend to #370, see the PR description for links to diffs
>> etc.
>>
>> I propose Alejandro as the shepherd, as he shepherded #370 before.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Joachim
>> --
>> --
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20210512/a85b7906/attachment.html>

From simonpj at microsoft.com  Thu May 13 15:09:07 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 13 May 2021 15:09:07 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
	design for dependent types
In-Reply-To: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Friends
You have now had a month to review my recommendation below, to accept #378: support for dependent types. Here it is once more<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
I have heard

  *   Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
  *   Against: no one
But that leaves Tom, Eric, Arnaud, Cale, Simon M, and Iavor who have not expressed an opinion.  Please do!
Failing further feedback, I'll accept on Tuesday next week.
There has been some further discussion on the pull request<https://github.com/ghc-proposals/ghc-proposals/pull/378>, but I don't think any fundamentally new points have come up.  This is clearly a judgement call, but one I think we should make.  Haskell has always been a research lab - that's part of what makes it distinctive.  I think we can continue to celebrate that innovation.  But see my email immediately below for what we are and are not accepting.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 15 April 2021 10:39
To: ghc-steering-committee at haskell.org
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Recommendation for #378: support the design for dependent types

Dear GHC steering committee
OK Richard has now revised the "Design for Dependent Types" proposal, and has resubmitted it.  As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it.
Here it is once more<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
I propose acceptance.
Remember:

  *   We would not be accepting every detail of the design in Section 4 - rather, we expect further specific proposals as we move in the direction described in the proposal.   So we should not debate the fine print of Section 4.
  *   We would be accepting that the proposal describes a direction of travel that we are happy with.  That in turn gives people the confidence to invest efforts in those more detailed proposals.  As the "Proposed change specification" says:  "When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features."
Any views?   Questions of clarification or technical questions belong on the comment stream.
Thanks
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee
Sent: 06 April 2021 13:58
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types

Richard and I have discussed this.
We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5Ywef9f5MK4jEc2XfmXeZ26YIdJeP0%2F%2BKfGdIhfkYA%3D&reserved=0>.  Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Sent: 29 March 2021 13:17
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Subject: Recommendation for #378: support the design for dependent types

Dear GHC Steering Committee
I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bf32VqzdL6HgiF436%2FGWPwBl09c1qo%2BAMbgPY6tJfSI%3D&reserved=0>
As you'll see, there is a lot of useful context, but the payload is pretty simple

When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1xOofIrHU3rP91mxYwvKnefFqCA5RBHCUUuKHqtdZlo%3D&reserved=0>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.

Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.

See also the committee's Review Criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2B6VLghDD03q1Qwqwytrp75eAHQtPF%2FB1SveNIKrymA%3D&reserved=0>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.

Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.
Any views?  Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210513/eb7238c2/attachment-0001.html>

From mail at joachim-breitner.de  Mon May 17 06:33:43 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 May 2021 08:33:43 +0200
Subject: [ghc-steering-committee] Please review #415: OPAQUE pragma,
 Shepherd: Tom
In-Reply-To: <9c0a55bc559f006dab55ee073c533bbfad904687.camel@joachim-breitner.de>
References: <5ff728d27bd506f90ce1201ea62764dfb458764f.camel@joachim-breitner.de>
 <AM5PR83MB03534D68AC42D6B6D5FBF342AD479@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAHnFXOuRcM1HmZDUmeAYzG4uOG=i05GGh7mMNznO_m3iYR_fYQ@mail.gmail.com>
 <7A0D6A9B-6F3C-4642-8F26-0675D7283445@live.co.uk>
 <CAH6fHQ=TGvGwcgcGSpmTJ-MdYh0bFN3tNy84iCR-zGQB8Qusaw@mail.gmail.com>
 <010f017919aec35b-ee84f52b-5d71-431c-9492-9015dd903c67-000000@us-east-2.amazonses.com>
 <F39CD36C-784A-4A50-B186-8287BE766C2F@live.co.uk>
 <9c0a55bc559f006dab55ee073c533bbfad904687.camel@joachim-breitner.de>
Message-ID: <bd6ad428f14f99430ef7bdab7bd539c812a7f324.camel@joachim-breitner.de>

Hi,

Am Montag, den 10.05.2021, 13:27 +0200 schrieb Joachim Breitner:
> Am Montag, den 10.05.2021, 10:06 +0000 schrieb Tom Harding:
> > Sorry for the delay - I’ve been moving house over the last fortnight, so I’ve been falling behind on my duties!
> > If I take silence to mean “no objections”, it sounds as though everyone with an opinion is in favour of this one; Joachim, are we OK to accept?
> 
> looks like it. Maybe we can wait until tomorrow for last minute
> expressions of opinions (I’m distracted today anyways)
> 

merging this now, sorry for the delay.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Mon May 17 06:48:41 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 May 2021 08:48:41 +0200
Subject: [ghc-steering-committee]  GHC Steering Committee Status
Message-ID: <efa86d1ae0c89d4c9616fb98453280a4e39cac99.camel@joachim-breitner.de>

Dear Committee,

are are keeping up a healthy pace, it seems, so time another status update.

So here’s the delta since April 5th.


 * we were asked to review these proposals:
  
   #415: OPAQUE pragma (Shepherd: Tom)
   #412: splice imports (Shepherd: Vladislav)
   #392: Clarify modifiers design principle (Shepherd: Alejandro)
   #351: NoIncomplete (back from revision, Shepherd: Iavor)
   #302: Lambda expressions with guards and multiple clauses (back from revision, Shepherd: Cale)

 * we have a recommendation from the shepherd about:

   #402: Stable GADT syntax (back from revision, accept)
   #378: support the design for dependent types (accept)
   #371: Stop treating ~ magically (back from revision, weak accept)
   #415: OPAQUE pragma (accept)
   #392: Clarify modifiers design principle (recommendation: acceptance)

 * we have sent the following proposals back to revision

   -none-   

 * we decided about the following proposals

   #402: Stable GADT syntax (accept)
   #371: Stop treating ~ magically (accept)
   #415: OPAQUE pragma (accept)


We currently have to act on the following 8 proposals, up by 2.

## Waiting for committee decision

#378: Support ergonomic dependent types, Shepherd: Simon PJ
      Recommendation is to accept, a few people have voiced
      their opinion, but Simon rightfully asked for more.

#392: Clarify modifiers design principle (Shepherd: Alejandro)
      One comment only so far, please add more.

## Waiting for Shepherd action

#283: Local modules, Shepherd: Arnaud
      Waiting for recommendation.
      No action since a while. Arnaud, can you pick this up?

#302: Lambda expressions with guards and multiple clauses, Shepherd: Cale
      This is back from revision, ready to be picked up.

#351: NoIncomplete, Shepherd: Iavor
      This is back from revision, ready to be picked up.

#400: Constrained COMPLETE sets, Shepherd: Cale
      Waiting for recommendation.
      No action since three months. Cale, can you drive this forward?

#409: Exportable named defaults, Shepherd: Eric
      Waiting for recommendation.
      No action since two months. Eric, any recommendation so far?

#412: splice imports (Shepherd: Vladislav)
      Waiting for recommendation.


Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Mon May 17 07:44:10 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 17 May 2021 07:44:10 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <efa86d1ae0c89d4c9616fb98453280a4e39cac99.camel@joachim-breitner.de>
References: <efa86d1ae0c89d4c9616fb98453280a4e39cac99.camel@joachim-breitner.de>
Message-ID: <AM5PR83MB03535E27E5C516B834DCFF03AD2D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Thanks for the update, Joachim

|  ## Waiting for Shepherd action

Arnaud, Cale, Iavor, Eric, we promise proposal authors a recommendation within a month [1] and hence a recommendation within a week or so.

I think that our Chief Nudger (Tom) will have been sending you weekly reminders about this.  Tom have you been doing this?

Could you possibly get on this?  We are all busy, I know.

Thanks

Simon

[1] https://github.com/ghc-proposals/ghc-proposals#committee-process-for-responding-to-a-proposal

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 17 May 2021 07:49
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] GHC Steering Committee Status
|  
|  Dear Committee,
|  
|  are are keeping up a healthy pace, it seems, so time another status
|  update.
|  
|  So here's the delta since April 5th.
|  
|  
|   * we were asked to review these proposals:
|  
|     #415: OPAQUE pragma (Shepherd: Tom)
|     #412: splice imports (Shepherd: Vladislav)
|     #392: Clarify modifiers design principle (Shepherd: Alejandro)
|     #351: NoIncomplete (back from revision, Shepherd: Iavor)
|     #302: Lambda expressions with guards and multiple clauses (back
|  from revision, Shepherd: Cale)
|  
|   * we have a recommendation from the shepherd about:
|  
|     #402: Stable GADT syntax (back from revision, accept)
|     #378: support the design for dependent types (accept)
|     #371: Stop treating ~ magically (back from revision, weak accept)
|     #415: OPAQUE pragma (accept)
|     #392: Clarify modifiers design principle (recommendation:
|  acceptance)
|  
|   * we have sent the following proposals back to revision
|  
|     -none-
|  
|   * we decided about the following proposals
|  
|     #402: Stable GADT syntax (accept)
|     #371: Stop treating ~ magically (accept)
|     #415: OPAQUE pragma (accept)
|  
|  
|  We currently have to act on the following 8 proposals, up by 2.
|  
|  ## Waiting for committee decision
|  
|  #378: Support ergonomic dependent types, Shepherd: Simon PJ
|        Recommendation is to accept, a few people have voiced
|        their opinion, but Simon rightfully asked for more.
|  
|  #392: Clarify modifiers design principle (Shepherd: Alejandro)
|        One comment only so far, please add more.
|  
|  ## Waiting for Shepherd action
|  
|  #283: Local modules, Shepherd: Arnaud
|        Waiting for recommendation.
|        No action since a while. Arnaud, can you pick this up?
|  
|  #302: Lambda expressions with guards and multiple clauses, Shepherd:
|  Cale
|        This is back from revision, ready to be picked up.
|  
|  #351: NoIncomplete, Shepherd: Iavor
|        This is back from revision, ready to be picked up.
|  
|  #400: Constrained COMPLETE sets, Shepherd: Cale
|        Waiting for recommendation.
|        No action since three months. Cale, can you drive this forward?
|  
|  #409: Exportable named defaults, Shepherd: Eric
|        Waiting for recommendation.
|        No action since two months. Eric, any recommendation so far?
|  
|  #412: splice imports (Shepherd: Vladislav)
|        Waiting for recommendation.
|  
|  
|  Cheers,
|  Joachim
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de

From arnaud.spiwack at tweag.io  Tue May 18 07:47:22 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 18 May 2021 09:47:22 +0200
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQm7OOL4QnW0-2E=FiGt_yHW5F9-Cozdv0VQkazF3MfCvg@mail.gmail.com>

Sorry, it's a long read. I'd read previous iterations of the proposal, and
the wiki page previously. But the current proposal is yet a different text,
I didn't want to opine without a proper reading.

The proposal is long, but doesn't really make a lot of concrete design
choices.

- Extend the name lookup in type syntax to lookup in the term namespace
when the name is absent in the type namespace
- A syntactic form `type …` to switch to the type namespace in terms
- Extend the term syntax to be a superset of the type syntax.
- Dependent Haskell is to be (mostly) backward compatible

I think that's about it. The rest establishes terminology and serves mostly
as documentation. And it does a pretty good job at it, I think.

The proposed changes seem reasonable.

The language, though, is sometimes interesting:

> By accepting this proposal, the committee reaffirms Haskell's status as
an evolving, forward-thinking language, excited to adopt new ideas.

> There remain a few individuals who appear to remain deeply unconvinced.
However, these seem to be a small minority. The reasons they are not
convinced appear to be around lack of understanding of the proposal/design
and general worry about unintended consequences. I have tried to address
both of these, but I do not believe my efforts have been fully successful.

This is really not helpful, I don't think that we want to merge the
proposal with this sort of language in it.

I'd add that the following:

> Many industrial Haskellers came out of the woodwork to support this
proposal.

is rather misleading, since there seem to have been just as many industrial
Haskellers which came out opposed to the proposal.

---

In summary: I'm in favour of the proposal, as long as Section 5 (Effect and
Interaction) and below, are cleaned of the politically charged language.

On Thu, May 13, 2021 at 5:09 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Friends
>
> You have now had a month to review my recommendation below, to accept
> #378: support for dependent types. Here it is once more
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
>
> I have heard
>
>    - Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
>    - Against: no one
>
> But that leaves *Tom, Eric, Arnaud, Cale, Simon M, and Iavor* who have
> not expressed an opinion.  Please do!
>
> Failing further feedback, I’ll accept on Tuesday next week.
>
> There has been some further discussion on the pull request
> <https://github.com/ghc-proposals/ghc-proposals/pull/378>, but I don’t
> think any fundamentally new points have come up.  This is clearly a
> judgement call, but one I think we should make.  Haskell has always been a
> research lab – that’s part of what makes it distinctive.  I think we can
> continue to celebrate that innovation.  But see my email immediately below
> for what we are and are not accepting.
>
> Simon
>
>
>
> *From:* Simon Peyton Jones <simonpj at microsoft.com>
> *Sent:* 15 April 2021 10:39
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Recommendation for #378: support the design for dependent types
>
>
>
> Dear GHC steering committee
>
> OK Richard has now revised the “Design for Dependent Types” proposal, and
> has resubmitted it.  As we asked, it now *includes* the design sketch
> that constitutes the direction of travel advocated in the proposal, rather
> than merely *referring* to it.
>
> Here it is once more
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
>
> I propose acceptance.
>
> Remember:
>
>    - We *would not* be accepting every detail of the design in Section 4
>    – rather, we expect further specific proposals as we move in the direction
>    described in the proposal.   So we should not debate the fine print of
>    Section 4.
>    - We *would* be accepting that the proposal describes a direction of
>    travel that we are happy with.  That in turn gives people the confidence to
>    invest efforts in those more detailed proposals.  As the “Proposed change
>    specification” says:  “When evaluating new proposals, the GHC committee
>    would consider compatibility with the design sketch below. Generally
>    speaking, new proposals should be forward-compatible with the design
>    sketch; that is, the new features proposed would continue to be at home
>    when surrounded by other dependent-type features.”
>
> Any views?   Questions of clarification or technical questions belong on
> the comment stream.
>
> Thanks
>
> Simon
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Peyton Jones via ghc-steering-committee
> *Sent:* 06 April 2021 13:58
> *To:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] Recommendation for #378: support
> the design for dependent types
>
>
>
> Richard and I have discussed this.
>
> We concluded that we’d put it back into “Needs revision” status. He’s
> going to expand it (substantially) to include *the proposed design sketch
> of dependent types on the GHC wiki
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5Ywef9f5MK4jEc2XfmXeZ26YIdJeP0%2F%2BKfGdIhfkYA%3D&reserved=0>.
> *Then he’ll resubmit in the hope of getting approval of the design in
> principle, subject to subsequent discussion of the fine detail.
>
> Simon
>
>
>
> *From:* Simon Peyton Jones <simonpj at microsoft.com>
> *Sent:* 29 March 2021 13:17
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Recommendation for #378: support the design for dependent types
>
>
>
> Dear GHC Steering Committee
>
> I’m recommending acceptance of Proposal #378: Support the design for
> dependent types
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bf32VqzdL6HgiF436%2FGWPwBl09c1qo%2BAMbgPY6tJfSI%3D&reserved=0>
>
> As you’ll see, there is a lot of useful context, but the payload is pretty
> simple
>
> *When evaluating new proposals, the GHC committee would consider
> compatibility with the proposed design sketch of dependent types on the GHC
> wiki
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1xOofIrHU3rP91mxYwvKnefFqCA5RBHCUUuKHqtdZlo%3D&reserved=0>.
> Generally speaking, new proposals should be forward-compatible with the
> design sketch; that is, the new features proposed would continue to be at
> home when surrounded by other dependent-type features.*
>
> *Of course, the committee remains free to revise the design sketch or to
> accept proposals that encroach upon it (i.e. contradicting this guidance),
> but such choices should be made explicitly.*
>
> *See also the committee's Review Criteria
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2B6VLghDD03q1Qwqwytrp75eAHQtPF%2FB1SveNIKrymA%3D&reserved=0>:
> put another way, this proposal says that we consider the design sketch
> alongside other features of today's Haskell when assessing a new proposal's
> fit with the language.*
>
> *Note that compatibility with dependent types is far from the only
> criterion the committee would use to evaluate a proposal. Other review
> criteria, such as learnability, clarity of error messages, performance,
> etc., remain just as ever.*
>
> Any views?  Let’s try to converge rapidly…. the proposal has been
> substantially refined by a lot of debate.
>
> Simon
> _______________________________________________
> 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/20210518/9ec75f11/attachment.html>

From rae at richarde.dev  Tue May 18 18:37:30 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 18 May 2021 18:37:30 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <CAH6fHQm7OOL4QnW0-2E=FiGt_yHW5F9-Cozdv0VQkazF3MfCvg@mail.gmail.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAH6fHQm7OOL4QnW0-2E=FiGt_yHW5F9-Cozdv0VQkazF3MfCvg@mail.gmail.com>
Message-ID: <010f017980c4c663-8b1455e5-9b6f-442e-b216-31004f46dd2f-000000@us-east-2.amazonses.com>



> On May 18, 2021, at 3:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Sorry, it's a long read. I'd read previous iterations of the proposal, and the wiki page previously. But the current proposal is yet a different text, I didn't want to opine without a proper reading.

Yes, thank you!

> 
> The proposal is long, but doesn't really make a lot of concrete design choices.

Yes, this is intentional.
> 
> The language, though, is sometimes interesting:
> 
> > By accepting this proposal, the committee reaffirms Haskell's status as an evolving, forward-thinking language, excited to adopt new ideas.

Yes, this was an overstep. I've struck this sentence.

> 
> > There remain a few individuals who appear to remain deeply unconvinced. However, these seem to be a small minority. The reasons they are not convinced appear to be around lack of understanding of the proposal/design and general worry about unintended consequences. I have tried to address both of these, but I do not believe my efforts have been fully successful.

I stand by this claim -- though I can see how the language here might be off-putting. This section is meant to be a summary of the discussion, and this really was a part of the discussion. However, I have replaced this bullet with a narrower one, describing the particular worry about people being forced to use dependent types because of early library adoption.

> 
> This is really not helpful, I don't think that we want to merge the proposal with this sort of language in it.
> 
> I'd add that the following:
> 
> > Many industrial Haskellers came out of the woodwork to support this proposal.
> 
> is rather misleading, since there seem to have been just as many industrial Haskellers which came out opposed to the proposal.

I disagree here. The GitHub ticket has 412 positive emotions, and 3 negative ones. The 412 might be an overcount, because I believe one individual can put multiple emoji on the same ticket, but there are at least 274 individuals in favor. It's true that I don't know how many of these are industrial users, but there were quite a few people who identified as industrial users in support. I actually don't know that any of the detractors identified themselves as industrial users, though I didn't read through all the comment trail to check this.

We don't -- and shouldn't -- operate solely (or primarily) on the basis of popularity, but I think both the emoji expressed and the comment trail suggests that this feature is desired in industry more widely than it is opposed.

Richard

> 
> ---
> 
> In summary: I'm in favour of the proposal, as long as Section 5 (Effect and Interaction) and below, are cleaned of the politically charged language.
> 
> On Thu, May 13, 2021 at 5:09 PM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> Friends
> 
> You have now had a month to review my recommendation below, to accept #378: support for dependent types. Here it is once more <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
> I have heard
> 
> Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
> Against: no one
> But that leaves Tom, Eric, Arnaud, Cale, Simon M, and Iavor who have not expressed an opinion.  Please do!
> 
> Failing further feedback, I’ll accept on Tuesday next week.
> 
> There has been some further discussion on the pull request <https://github.com/ghc-proposals/ghc-proposals/pull/378>, but I don’t think any fundamentally new points have come up.  This is clearly a judgement call, but one I think we should make.  Haskell has always been a research lab – that’s part of what makes it distinctive.  I think we can continue to celebrate that innovation.  But see my email immediately below for what we are and are not accepting.
> 
> Simon
> 
>  
> 
> From: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> 
> Sent: 15 April 2021 10:39
> To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Cc: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Subject: Recommendation for #378: support the design for dependent types
>  
> 
> Dear GHC steering committee
> 
> OK Richard has now revised the “Design for Dependent Types” proposal, and has resubmitted it.  As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it.
> 
> Here it is once more <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
> I propose acceptance.
> 
> Remember:
> 
> We would not be accepting every detail of the design in Section 4 – rather, we expect further specific proposals as we move in the direction described in the proposal.   So we should not debate the fine print of Section 4. 
> We would be accepting that the proposal describes a direction of travel that we are happy with.  That in turn gives people the confidence to invest efforts in those more detailed proposals.  As the “Proposed change specification” says:  “When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.”
> Any views?   Questions of clarification or technical questions belong on the comment stream.
> 
> Thanks
> 
> Simon
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee
> Sent: 06 April 2021 13:58
> To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types
>  
> 
> Richard and I have discussed this.
> 
> We concluded that we’d put it back into “Needs revision” status. He’s going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5Ywef9f5MK4jEc2XfmXeZ26YIdJeP0%2F%2BKfGdIhfkYA%3D&reserved=0>.  Then he’ll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail.
> 
> Simon
> 
>  
> 
> From: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> 
> Sent: 29 March 2021 13:17
> To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Cc: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Subject: Recommendation for #378: support the design for dependent types
>  
> 
> Dear GHC Steering Committee
> 
> I’m recommending acceptance of Proposal #378: Support the design for dependent types <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bf32VqzdL6HgiF436%2FGWPwBl09c1qo%2BAMbgPY6tJfSI%3D&reserved=0>
> As you’ll see, there is a lot of useful context, but the payload is pretty simple
> 
> When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1xOofIrHU3rP91mxYwvKnefFqCA5RBHCUUuKHqtdZlo%3D&reserved=0>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.
> 
> Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.
> 
> See also the committee's Review Criteria <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2B6VLghDD03q1Qwqwytrp75eAHQtPF%2FB1SveNIKrymA%3D&reserved=0>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.
> 
> Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.
> 
> Any views?  Let’s try to converge rapidly…. the proposal has been substantially refined by a lot of debate.
> 
> Simon
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20210518/a2df82dc/attachment-0001.html>

From iavor.diatchki at gmail.com  Tue May 18 18:52:46 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 18 May 2021 11:52:46 -0700
Subject: [ghc-steering-committee] Stepping down from the committee
Message-ID: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>

Hello,

I think it is time for me to step down from the GHC committee---lately I
find that I don't have the enthusiasm I used to have for reviewing or
discussing proposals, so it makes sense to make space for someone who is
passionate about doing this work.

Thanks for working with me, and I am looking forward to having a beer with
you all at ICFP once the world reopens!

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210518/0074d46a/attachment.html>

From eric at seidel.io  Wed May 19 02:11:48 2021
From: eric at seidel.io (Eric Seidel)
Date: Tue, 18 May 2021 22:11:48 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?=23409=3A_Exportable_named_def?=
 =?utf-8?q?aults=2C_Recommendation=3A_Partial_Accept?=
In-Reply-To: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
Message-ID: <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>

Hi all,

Mario has proposed a handful of language extensions around type defaulting.

1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.

2. ExportedDefaults: this extension allows exporting defaulting rules.

3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.

Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.

My recommendation is that we

* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.

* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. 

Please take a look at the proposal.

Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409
Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst

Eric

On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
> Dear Committe,
> 
> Exportable named defaults
> has been proposed by Mario
> https://github.com/ghc-proposals/ghc-proposals/pull/409
> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
> 
> I propose Eric as the Shepherd.
> 
> This did not gather a lot of attention on Github, or rather none, so
> Eric, maybe also consider whether this needs to be advertised more, or
> maybe who should be pointed to it.
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
> -- 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

From arnaud.spiwack at tweag.io  Wed May 19 06:10:55 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 19 May 2021 08:10:55 +0200
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <010f017980c4c663-8b1455e5-9b6f-442e-b216-31004f46dd2f-000000@us-east-2.amazonses.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <CAH6fHQm7OOL4QnW0-2E=FiGt_yHW5F9-Cozdv0VQkazF3MfCvg@mail.gmail.com>
 <010f017980c4c663-8b1455e5-9b6f-442e-b216-31004f46dd2f-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQmhROxmuXFYeqaCXr7QW=x3yEwKn5LJb4uC9KM=TrjRug@mail.gmail.com>

On Tue, May 18, 2021 at 8:37 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
> > There remain a few individuals who appear to remain deeply unconvinced.
> However, these seem to be a small minority. The reasons they are not
> convinced appear to be around lack of understanding of the proposal/design
> and general worry about unintended consequences. I have tried to address
> both of these, but I do not believe my efforts have been fully successful.
>
>
> I stand by this claim -- though I can see how the language here might be
> off-putting. This section is meant to be a summary of the discussion, and
> this really was a part of the discussion. However, I have replaced this
> bullet with a narrower one, describing the particular worry about people
> being forced to use dependent types because of early library adoption.
>

You are claiming that they don't agree with the proposal because they don't
understand. It's a very strong claim to make. But you've changed the
sentence already, so I guess no point in arguing further.


>
>
> > Many industrial Haskellers came out of the woodwork to support this
> proposal.
>
> is rather misleading, since there seem to have been just as many
> industrial Haskellers which came out opposed to the proposal.
>
>
> I disagree here. The GitHub ticket has 412 positive emotions, and 3
> negative ones. The 412 might be an overcount, because I believe one
> individual can put multiple emoji on the same ticket, but there are at
> least 274 individuals in favor. It's true that I don't know how many of
> these are industrial users, but there were quite a few people who
> identified as industrial users in support. I actually don't know that any
> of the detractors identified themselves as industrial users, though I
> didn't read through all the comment trail to check this.
>
> We don't -- and shouldn't -- operate solely (or primarily) on the basis of
> popularity, but I think both the emoji expressed and the comment trail
> suggests that this feature is desired in industry more widely than it is
> opposed.
>

There is no doubt that the idea of Dependent Haskell is popular (Dependent
Haskell in general, and this proposal in particular), but I'm not sure that
this is what your sentence is claiming (I wouldn't object to this claim!).
If it's not misleading, this claim is at least very hard to verify. It does
make me uncomfortable (as for industrial contradictors I remember Matt
Parsons being one of them).

PS: I didn't mean to imply that there being few claims/design choices in
the proposal was a bad thing. I suppose, though, that like many such
high-level summaries of a thing one comments, it was meant mostly for my
own consumption, to ground my reasoning.

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210519/38271e38/attachment.html>

From mail at joachim-breitner.de  Wed May 19 07:17:58 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 19 May 2021 09:17:58 +0200
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
Message-ID: <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>

Hello Iavor,

I’m sad to you see leave, and you will leave an hole in the committee.
I have always greatly valued your particular perspective on these
matters, and fear that it will be underrepresented in the committee in
the future. We’ll need to keep “what would Iavor say to this” in the
back of our heads from now on…

50 months is an impressive time to spend on a project like this, and if
interests shift and it becomes less rewarding than it used to be, then
stepping down is the right step to do. Should you ever change your
mind, I’ll be happy to see your name on the ballot!

Cheers, and looking forward to see you at a conference at some point,
Joachim


Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
> I think it is time for me to step down from the GHC committee---
> lately I find that I don't have the enthusiasm I used to have for
> reviewing or discussing proposals, so it makes sense to make space
> for someone who is passionate about doing this work.
> 
> Thanks for working with me, and I am looking forward to having a beer
> with you all at ICFP once the world reopens!
> 
> -Iavor
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Wed May 19 07:22:43 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 19 May 2021 09:22:43 +0200
Subject: [ghc-steering-committee]  Please review #351: NoIncomplete,
 Shepherd: Vitaly
Message-ID: <0ba7ca3ca0d8053d3e13c912e516a395f097fa0d.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

The NoIncomplete pragma
has been proposed by John Ericson
https://github.com/ghc-proposals/ghc-proposals/pull/351
https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-sugared-incompleteness.rst

This was shepherded by Iavor, who stepped down, and I suggest Vitaly
takes over. Vitaly, maybe comment on the Github thread in an
encouraging way, to reduce frustration by the author about the longer
than usual delay.


Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Wed May 19 07:41:23 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 19 May 2021 09:41:23 +0200
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
Message-ID: <c8b6b8982fd4e7e5df820c0f3696e9d1454bccef.camel@joachim-breitner.de>

Hi Eric,

I agree that this proposal is really two proposals that are relatively
orthogonal (defaults for other type classes, and defaults across
modules). Worth splitting maybe?

Following your recommendation, focusing on NamedDefaults first.

Indeed, if he had the ability to write

  default IsString (T.Text)

I might have voted OverloadedStrings into Haskell2021 :-)

So definitely a valuable proposal, but I think we some questions are
unanswered yet.

For 
   default A (Int,String,())
   default B (String,(),Int)
   (A t, B t) => t
it says “just don't do that;”.

But doesn’t that imply that, if one wants to rule out all use-site
conflicts, there must be a global priority ordering of types across all
defaultable type classes where each individual default clause is a
subsequence of? Would it then make sense to just statically forbid such
“illegal” orderings, i.e. reject if two default declarations are in
scope that could lead to that? Would that rule out declarations that
we’d want to allow?


And then there are the multi-parameter type classes… they are discussed
in the end, but not part of the proposal.
I kinda feel that instead of taking one small step here, we should aim
a bit higher and find something that works not just for some type
classes, but most of them out there. Or at least understand why that
would not be possible/desirable.


That said, I don’t consider myself an expert on type class defaulting,
so happy to hear other’s opinions here.


Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Wed May 19 16:17:58 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 19 May 2021 16:17:58 +0000
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
Message-ID: <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>

How does this proposal compare to https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulting-plugins.rst <https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulting-plugins.rst> ? That alternative proposal was ruled "out of scope", because it describes a plugin interface, which is out of scope of this committee. But I think it's a viable alternative to Mario's proposal here, and appears to be more powerful (although more difficult to use). I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued.

Richard

> On May 18, 2021, at 10:11 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> Hi all,
> 
> Mario has proposed a handful of language extensions around type defaulting.
> 
> 1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.
> 
> 2. ExportedDefaults: this extension allows exporting defaulting rules.
> 
> 3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.
> 
> Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.
> 
> My recommendation is that we
> 
> * Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.
> 
> * Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. 
> 
> Please take a look at the proposal.
> 
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409
> Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
> 
> Eric
> 
> On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
>> Dear Committe,
>> 
>> Exportable named defaults
>> has been proposed by Mario
>> https://github.com/ghc-proposals/ghc-proposals/pull/409
>> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
>> 
>> I propose Eric as the Shepherd.
>> 
>> This did not gather a lot of attention on Github, or rather none, so
>> Eric, maybe also consider whether this needs to be advertised more, or
>> maybe who should be pointed to it.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> 
>> Thanks,
>> Joachim
>> -- 
>> -- 
>> Joachim Breitner
>>  mail at joachim-breitner.de
>>  http://www.joachim-breitner.de/
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
> _______________________________________________
> 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/20210519/05674829/attachment.html>

From rae at richarde.dev  Wed May 19 16:21:48 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 19 May 2021 16:21:48 +0000
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
 <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
Message-ID: <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>

I wholeheartedly agree with Joachim here. I was sad to see Iavor's note and contemplating writing a plea to stay on -- but then wanted to respect your decision. Despite the fact, Iavor, that you and I often have been on opposing sides of a debate, it's a pleasure to work with you, and I will miss your voice in this committee.

Thanks for all your contributions!

Richard

> On May 19, 2021, at 3:17 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hello Iavor,
> 
> I’m sad to you see leave, and you will leave an hole in the committee.
> I have always greatly valued your particular perspective on these
> matters, and fear that it will be underrepresented in the committee in
> the future. We’ll need to keep “what would Iavor say to this” in the
> back of our heads from now on…
> 
> 50 months is an impressive time to spend on a project like this, and if
> interests shift and it becomes less rewarding than it used to be, then
> stepping down is the right step to do. Should you ever change your
> mind, I’ll be happy to see your name on the ballot!
> 
> Cheers, and looking forward to see you at a conference at some point,
> Joachim
> 
> 
> Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
>> I think it is time for me to step down from the GHC committee---
>> lately I find that I don't have the enthusiasm I used to have for
>> reviewing or discussing proposals, so it makes sense to make space
>> for someone who is passionate about doing this work.
>> 
>> Thanks for working with me, and I am looking forward to having a beer
>> with you all at ICFP once the world reopens!
>> 
>> -Iavor
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Wed May 19 18:46:08 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 19 May 2021 20:46:08 +0200
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>
Message-ID: <3e11cef15a8d3a2a90c7065b6ae74c5dc3736dbe.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 19.05.2021, 16:17 +0000 schrieb Richard Eisenberg:
> I'm worried that the "out of scope" label derailed the plugins
> proposal, as I do not believe that further work on that idea (even
> though it's already implemented!) has been pursued.

we could rename it to “no-decision-needed” or something like that?

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Wed May 19 20:52:52 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 19 May 2021 20:52:52 +0000
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <3e11cef15a8d3a2a90c7065b6ae74c5dc3736dbe.camel@joachim-breitner.de>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>
 <3e11cef15a8d3a2a90c7065b6ae74c5dc3736dbe.camel@joachim-breitner.de>
Message-ID: <010f01798667133f-40d5b99e-1dfa-4411-990b-1984cfd4b8b1-000000@us-east-2.amazonses.com>



> On May 19, 2021, at 2:46 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> we could rename it to “no-decision-needed” or something like that?

Well, it depends on the subject. If someone posts a proposal describing a new field in a cabal file, that's out of scope. But somehow this plugin suggestion is different: it solves the kind of problem that other proposals solve, but the solution just happens not to fit the usual format (and is beyond our purview). So maybe we have both "no approval needed" and "out of scope", and apply them in the two different situations.

All that said, I'd rather not derail this thread further: I'm still keen on figuring out whether Mario's proposal is a better way forward than using a plugin. My instinct -- especially in light of Joachim's questions earlier, which will need answers -- is that a plugin is a lower-stakes way forward. If we support the plugin architecture and we gain experience in light of it, we can consider adding a proper language feature.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210519/693a1af0/attachment.html>

From simonpj at microsoft.com  Wed May 19 21:24:33 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 May 2021 21:24:33 +0000
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
 <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
 <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>
Message-ID: <AM5PR83MB0353854FDF53142F14315B31AD2B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>

Iavor

I too would like to thank you very much.  You have been a big contributor to Haskell for a long time, and I've really appreciated your input to the GHC steering committee.

Thank you!

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Richard Eisenberg
|  Sent: 19 May 2021 17:22
|  To: Joachim Breitner <mail at joachim-breitner.de>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Stepping down from the committee
|  
|  I wholeheartedly agree with Joachim here. I was sad to see Iavor's note and
|  contemplating writing a plea to stay on -- but then wanted to respect your
|  decision. Despite the fact, Iavor, that you and I often have been on
|  opposing sides of a debate, it's a pleasure to work with you, and I will
|  miss your voice in this committee.
|  
|  Thanks for all your contributions!
|  
|  Richard
|  
|  > On May 19, 2021, at 3:17 AM, Joachim Breitner <mail at joachim-breitner.de>
|  wrote:
|  >
|  > Hello Iavor,
|  >
|  > I'm sad to you see leave, and you will leave an hole in the committee.
|  > I have always greatly valued your particular perspective on these
|  > matters, and fear that it will be underrepresented in the committee in
|  > the future. We'll need to keep "what would Iavor say to this" in the
|  > back of our heads from now on...
|  >
|  > 50 months is an impressive time to spend on a project like this, and
|  > if interests shift and it becomes less rewarding than it used to be,
|  > then stepping down is the right step to do. Should you ever change
|  > your mind, I'll be happy to see your name on the ballot!
|  >
|  > Cheers, and looking forward to see you at a conference at some point,
|  > Joachim
|  >
|  >
|  > Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
|  >> I think it is time for me to step down from the GHC committee---
|  >> lately I find that I don't have the enthusiasm I used to have for
|  >> reviewing or discussing proposals, so it makes sense to make space
|  >> for someone who is passionate about doing this work.
|  >>
|  >> Thanks for working with me, and I am looking forward to having a beer
|  >> with you all at ICFP once the world reopens!
|  >>
|  >> -Iavor
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org
|  >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
|  >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee
|  >> &amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d08d
|  >> 91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63757038144964
|  >> 8409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
|  >> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4LEUMtHN%2BS1k7wqTngaJAuq
|  >> WXCG%2BE%2FTRp6f8BG7kzxI%3D&amp;reserved=0
|  > --
|  > Joachim Breitner
|  >  mail at joachim-breitner.de
|  >
|  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  > oachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a
|  > 7b89435ee4bb2b68d08d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
|  > C0%7C637570381449658400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
|  > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=synnK38S
|  > Prg%2BgU0xol0v%2Fu5qakT9cLJ7vLzHm%2FISojk%3D&amp;reserved=0
|  >
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org
|  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
|  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
|  > mp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d08d91a
|  > e2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400
|  > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
|  > k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7
|  > l8cw44b4YssI%3D&amp;reserved=0
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
|  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d0
|  8d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400%
|  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
|  LCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7l8cw44b4YssI%
|  3D&amp;reserved=0

From eric at seidel.io  Thu May 20 00:28:16 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 19 May 2021 20:28:16 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?=23409=3A_Exportable_named_def?=
 =?utf-8?q?aults=2C_Recommendation=3A_Partial_Accept?=
In-Reply-To: <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <010f0179856b640e-201c702d-c287-4628-9bf9-d62126f1643e-000000@us-east-2.amazonses.com>
Message-ID: <2d5516de-f405-4003-8f56-48c6cf6652ce@www.fastmail.com>

Thanks for reminding me again of this proposal, plugins actually came to my mind as well when I was writing my recommendation for Mario's proposal.

- The barrier to entry is significantly raised with a plugin, both for authors and users. This is likely fine for the purpose of experimentation, but I think we should be clear that plugins are not a long-term solution here. 
- The flip side of the above is that we're not at all tied to any particular design in the interim.
- The plugin API neatly provides a way to "export" defaulting rules, but it doesn't really seem to address the conflict-resolution aspect of Mario's proposal. If I enable multiple defaulting plugins with conflicting rules, how does defaulting work? Presumably it boils down to the order in which the plugins are installed, and I either have to manage that or write my own plugin, both of which seem painful. Mario's solution of writing another defaulting rule in the current module is much cleaner, and *more likely to actually see use*.
- So I'm worried that a defaulting plugin API will be unwieldy enough that we won't see much experimentation in exactly the area I want to see experimentation, how do we share defaulting rules and resolve conflicts.
- Could we write a *generic* defaulting plugin that would allow sharing user-defined rules? Maybe, I can kind of imagine how you could write dummy values that the plugin interprets as defaulting rules, and which can then be exported and imported as usual. I think that's an intriguing idea that might be lightweight enough to see use and let us experiment with different rules around sharing, coherence, and conflict resolution.

Eric

On Wed, May 19, 2021, at 12:17, Richard Eisenberg wrote:
> How does this proposal compare to 
> https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulting-plugins.rst ? That alternative proposal was ruled "out of scope", because it describes a plugin interface, which is out of scope of this committee. But I think it's a viable alternative to Mario's proposal here, and appears to be more powerful (although more difficult to use). I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued.
> 
> Richard
> 
> > On May 18, 2021, at 10:11 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > Hi all,
> > 
> > Mario has proposed a handful of language extensions around type defaulting.
> > 
> > 1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.
> > 
> > 2. ExportedDefaults: this extension allows exporting defaulting rules.
> > 
> > 3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.
> > 
> > Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.
> > 
> > My recommendation is that we
> > 
> > * Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.
> > 
> > * Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. 
> > 
> > Please take a look at the proposal.
> > 
> > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409
> > Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
> > 
> > Eric
> > 
> > On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
> >> Dear Committe,
> >> 
> >> Exportable named defaults
> >> has been proposed by Mario
> >> https://github.com/ghc-proposals/ghc-proposals/pull/409
> >> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
> >> 
> >> I propose Eric as the Shepherd.
> >> 
> >> This did not gather a lot of attention on Github, or rather none, so
> >> Eric, maybe also consider whether this needs to be advertised more, or
> >> maybe who should be pointed to it.
> >> 
> >> Please guide us to a conclusion as outlined in 
> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >> 
> >> Thanks,
> >> Joachim
> >> -- 
> >> -- 
> >> Joachim Breitner
> >>  mail at joachim-breitner.de
> >>  http://www.joachim-breitner.de/
> >> 
> >> 
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >> 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

From eric at seidel.io  Thu May 20 00:36:40 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 19 May 2021 20:36:40 -0400
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <AM5PR83MB0353854FDF53142F14315B31AD2B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
 <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
 <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>
 <AM5PR83MB0353854FDF53142F14315B31AD2B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <62fa128e-68d2-445c-8197-4f937227e5f5@www.fastmail.com>

I'll echo everyone else. I've also greatly enjoyed working with you over the years, and will miss your arguments for keeping Haskell a simpler language.

Thanks Iavor!

Eric

On Wed, May 19, 2021, at 17:24, Simon Peyton Jones via ghc-steering-committee wrote:
> Iavor
> 
> I too would like to thank you very much.  You have been a big 
> contributor to Haskell for a long time, and I've really appreciated 
> your input to the GHC steering committee.
> 
> Thank you!
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
> |  Behalf Of Richard Eisenberg
> |  Sent: 19 May 2021 17:22
> |  To: Joachim Breitner <mail at joachim-breitner.de>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] Stepping down from the committee
> |  
> |  I wholeheartedly agree with Joachim here. I was sad to see Iavor's note and
> |  contemplating writing a plea to stay on -- but then wanted to respect your
> |  decision. Despite the fact, Iavor, that you and I often have been on
> |  opposing sides of a debate, it's a pleasure to work with you, and I will
> |  miss your voice in this committee.
> |  
> |  Thanks for all your contributions!
> |  
> |  Richard
> |  
> |  > On May 19, 2021, at 3:17 AM, Joachim Breitner <mail at joachim-breitner.de>
> |  wrote:
> |  >
> |  > Hello Iavor,
> |  >
> |  > I'm sad to you see leave, and you will leave an hole in the committee.
> |  > I have always greatly valued your particular perspective on these
> |  > matters, and fear that it will be underrepresented in the committee in
> |  > the future. We'll need to keep "what would Iavor say to this" in the
> |  > back of our heads from now on...
> |  >
> |  > 50 months is an impressive time to spend on a project like this, and
> |  > if interests shift and it becomes less rewarding than it used to be,
> |  > then stepping down is the right step to do. Should you ever change
> |  > your mind, I'll be happy to see your name on the ballot!
> |  >
> |  > Cheers, and looking forward to see you at a conference at some point,
> |  > Joachim
> |  >
> |  >
> |  > Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
> |  >> I think it is time for me to step down from the GHC committee---
> |  >> lately I find that I don't have the enthusiasm I used to have for
> |  >> reviewing or discussing proposals, so it makes sense to make space
> |  >> for someone who is passionate about doing this work.
> |  >>
> |  >> Thanks for working with me, and I am looking forward to having a beer
> |  >> with you all at ICFP once the world reopens!
> |  >>
> |  >> -Iavor
> |  >> _______________________________________________
> |  >> ghc-steering-committee mailing list
> |  >> ghc-steering-committee at haskell.org
> |  >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
> |  >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee
> |  >> &amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d08d
> |  >> 91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63757038144964
> |  >> 8409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> |  >> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4LEUMtHN%2BS1k7wqTngaJAuq
> |  >> WXCG%2BE%2FTRp6f8BG7kzxI%3D&amp;reserved=0
> |  > --
> |  > Joachim Breitner
> |  >  mail at joachim-breitner.de
> |  >
> |  > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
> |  > oachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a
> |  > 7b89435ee4bb2b68d08d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> |  > C0%7C637570381449658400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> |  > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=synnK38S
> |  > Prg%2BgU0xol0v%2Fu5qakT9cLJ7vLzHm%2FISojk%3D&amp;reserved=0
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> |  > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
> |  > mp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d08d91a
> |  > e2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400
> |  > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> |  > k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7
> |  > l8cw44b4YssI%3D&amp;reserved=0
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
> |  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C07a7b89435ee4bb2b68d0
> |  8d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400%
> |  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> |  LCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7l8cw44b4YssI%
> |  3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

From eric at seidel.io  Thu May 20 02:21:46 2021
From: eric at seidel.io (Eric Seidel)
Date: Wed, 19 May 2021 22:21:46 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Recommendation_for_=23378=3A_s?=
 =?utf-8?q?upport_the=09design_for_dependent_types?=
In-Reply-To: <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <31bd8058-baa8-47e1-84bf-ad4f3fd9a74b@www.fastmail.com>

I've read through the whole proposal again. 

Thanks, Richard, for all the work you've put in to revising it. It's a much better proposal than when this started.

After reading through it again, I find myself feeling about the same as I did originally: open to the idea of dependent types in Haskell, but concerned about some of the details.

Interestingly, I found myself largely nodding along with much of the actual design in section 4, but am still unconvinced by the proposals referenced in section 1 that motivated this whole thing.

I'll reply here to a few pieces of the proposal, since my comments are more about viewpoints than technical details.

> Rejecting #291 amounts to prioritizing criterion 1; accepting it amounts to prioritizing criterion 2.

I still disagree that this proposal has much of anything to do with dependent types. Repeat occurrences of the same binder asserting type equality is a useful feature (the same would be true for term binders, I think I mentioned that in an earlier thread).

> On the other hand, #281 could be simplified considerably if it did not need to deal with the possibility of type/term ambiguity: that is, if there were no puns. For example, we could declare that the use of any punned identifier in a type argument is an error.

This doesn't seem at all compatible with the reality that Haskell has two namespaces, unless the point is that punned identifiers will need to be manually disambiguated with the `type/data` heralds mentioned later. If that's the case (I suspect so), the proposal should be more explicit about the expected resolution.

> The Opt-In Principle (OIP): Users who do not opt into dependent types will not be affected by them. By "opt into", we mean that users would have to enable -XDependentTypes or import a module that exposes functions with dependently-typed interfaces. These modules would not be standard modules that are routinely imported today, such as Data.List or Prelude.

This is a good principle, but I think you may be trying to have your cake and eat it too. I spent much of the past few years working in C++, which is a cautionary tale for complex language features. In particular, they end up everywhere, especially in core libraries, because generic, core libraries are precisely where you need all that extra power and expressiveness. Recently, I've been working in Scala, where I've observed the same thing. This is not to say that dependent types are bound to appear everywhere, they're a different feature, and C++ and Scala are infamous for their complexity, but I think it will be harder than you admit to keep core libraries free of dependent types. I'm also very glad to see in the following paragraph that you're thinking about ways to hide the complexity from users that don't need to worry about it, please keep that up!

> 4.4   Quantifiers

I'm pretty concerned about adding 3 more quantifiers to keep track of. The breakdown makes sense, but it's a lot of extra cognitive burden. I'm sure you would argue that these only become relevant in advanced use cases, but see above about the OIP.

---

On balance, I think you've done a commendable job of designing these features and principles to minimize disruption to existing code and users. What remains to be seen is how the community adopts and uses these features, and whether that creates a fork in the ecosystem. I will support this proposal, but will hold you to your promise to keep at least a veneer of simplicity over these features (like with $ and levity-polymorphism).

Thanks!
Eric



On Thu, May 13, 2021, at 11:09, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> Friends
> 
> You have now had a month to review my recommendation below, to accept 
> #378: support for dependent types. Here it is once more 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
> 
> I have heard 
> 
>  * Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
>  * Against: no one
> But that leaves *Tom, Eric, Arnaud, Cale, Simon M, and Iavor* who have 
> not expressed an opinion.  Please do!
> 
> Failing further feedback, I’ll accept on Tuesday next week.
> 
> There has been some further discussion on the pull request 
> <https://github.com/ghc-proposals/ghc-proposals/pull/378>, but I don’t 
> think any fundamentally new points have come up.  This is clearly a 
> judgement call, but one I think we should make.  Haskell has always 
> been a research lab – that’s part of what makes it distinctive.  I 
> think we can continue to celebrate that innovation.  But see my email 
> immediately below for what we are and are not accepting.
> 
> Simon
> 
>  
> 
> *From:* Simon Peyton Jones <simonpj at microsoft.com> 
> *Sent:* 15 April 2021 10:39
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Recommendation for #378: support the design for dependent types
> 
>  
> 
> Dear GHC steering committee
> 
> OK Richard has now revised the “Design for Dependent Types” proposal, 
> and has resubmitted it.  As we asked, it now *includes* the design 
> sketch that constitutes the direction of travel advocated in the 
> proposal, rather than merely *referring* to it.
> 
> Here it is once more 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0>
> 
> I propose acceptance.
> 
> Remember:
> 
>  * We *would not* be accepting every detail of the design in Section 4 
> – rather, we expect further specific proposals as we move in the 
> direction described in the proposal.   So we should not debate the fine 
> print of Section 4.  
>  * We *would* be accepting that the proposal describes a direction of 
> travel that we are happy with.  That in turn gives people the 
> confidence to invest efforts in those more detailed proposals.  As the 
> “Proposed change specification” says:  “When evaluating new proposals, 
> the GHC committee would consider compatibility with the design sketch 
> below. Generally speaking, new proposals should be forward-compatible 
> with the design sketch; that is, the new features proposed would 
> continue to be at home when surrounded by other dependent-type 
> features.”
> Any views?   Questions of clarification or technical questions belong 
> on the comment stream.
> 
> Thanks
> 
> Simon
> 
> *From:* ghc-steering-committee 
> <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon 
> Peyton Jones via ghc-steering-committee
> *Sent:* 06 April 2021 13:58
> *To:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] Recommendation for #378: 
> support the design for dependent types
> 
>  
> 
> Richard and I have discussed this.
> 
> We concluded that we’d put it back into “Needs revision” status. He’s 
> going to expand it (substantially) to include *the proposed design 
> sketch of dependent types on the GHC wiki 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5Ywef9f5MK4jEc2XfmXeZ26YIdJeP0%2F%2BKfGdIhfkYA%3D&reserved=0>.  *Then he’ll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail.
> 
> Simon
> 
>  
> 
> *From:* Simon Peyton Jones <simonpj at microsoft.com> 
> *Sent:* 29 March 2021 13:17
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Recommendation for #378: support the design for dependent types
> 
>  
> 
> Dear GHC Steering Committee
> 
> I’m recommending acceptance of Proposal #378: Support the design for 
> dependent types 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bf32VqzdL6HgiF436%2FGWPwBl09c1qo%2BAMbgPY6tJfSI%3D&reserved=0>
> 
> As you’ll see, there is a lot of useful context, but the payload is 
> pretty simple
> 
> *When evaluating new proposals, the GHC committee would consider 
> compatibility with the proposed design sketch of dependent types on the 
> GHC wiki 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1xOofIrHU3rP91mxYwvKnefFqCA5RBHCUUuKHqtdZlo%3D&reserved=0>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.*
> 
> *Of course, the committee remains free to revise the design sketch or 
> to accept proposals that encroach upon it (i.e. contradicting this 
> guidance), but such choices should be made explicitly.*
> 
> *See also the committee's Review Criteria 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2B6VLghDD03q1Qwqwytrp75eAHQtPF%2FB1SveNIKrymA%3D&reserved=0>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.*
> 
> *Note that compatibility with dependent types is far from the only 
> criterion the committee would use to evaluate a proposal. Other review 
> criteria, such as learnability, clarity of error messages, performance, 
> etc., remain just as ever.*
> 
> Any views?  Let’s try to converge rapidly…. the proposal has been 
> substantially refined by a lot of debate.
> 
> Simon
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee%40haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

From bravit111 at gmail.com  Thu May 20 06:41:41 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Thu, 20 May 2021 09:41:41 +0300
Subject: [ghc-steering-committee] Please review #351: NoIncomplete,
 Shepherd: Vitaly
In-Reply-To: <0ba7ca3ca0d8053d3e13c912e516a395f097fa0d.camel@joachim-breitner.de>
References: <0ba7ca3ca0d8053d3e13c912e516a395f097fa0d.camel@joachim-breitner.de>
Message-ID: <CALpVSmNJ9qmYHyyEoNmn9A=DQrVNUL6fDVx3AAnYdW4VNPT_Gw@mail.gmail.com>

Thank you, Joachim. I'm on it.

Vitaly

ср, 19 мая 2021 г. в 10:23, Joachim Breitner <mail at joachim-breitner.de>:

> Dear Committee,
>
> this is your secretary speaking:
>
> The NoIncomplete pragma
> has been proposed by John Ericson
> https://github.com/ghc-proposals/ghc-proposals/pull/351
>
> https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-sugared-incompleteness.rst
>
> This was shepherded by Iavor, who stepped down, and I suggest Vitaly
> takes over. Vitaly, maybe comment on the Github thread in an
> encouraging way, to reduce frustration by the author about the longer
> than usual delay.
>
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20210520/ecced1bc/attachment.html>

From mail at joachim-breitner.de  Thu May 20 06:58:11 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 20 May 2021 08:58:11 +0200
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <31bd8058-baa8-47e1-84bf-ad4f3fd9a74b@www.fastmail.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <31bd8058-baa8-47e1-84bf-ad4f3fd9a74b@www.fastmail.com>
Message-ID: <d565c61bf6a9b8ca6972083e5371d4e8dec22f5e.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 19.05.2021, 22:21 -0400 schrieb Eric Seidel:
> > The Opt-In Principle (OIP): Users who do not opt into dependent
> > types will not be affected by them. By "opt into", we mean that
> > users would have to enable -XDependentTypes or import a module that
> > exposes functions with dependently-typed interfaces. These modules
> > would not be standard modules that are routinely imported today,
> > such as Data.List or Prelude.
> 
> This is a good principle, but I think you may be trying to have your
> cake and eat it too. 

I am actually not opposed to compromising on the OIP, and would not
mind seeing new features of Haskell be used in basic libraries where
they make sense.

Base has `HasCallStack`. It has Rank2Polymorphism. It has type
equalities. It has generics, and thus associated types.


I am not opposed to keeping simple things simple, and just along the
desire to break no more code than necessary as we change basic
libraries will help. But overall I’d rather compromise on OIP than on,
say, using the right tool for the right problem.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From trupill at gmail.com  Thu May 20 15:24:42 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 20 May 2021 10:24:42 -0500
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
Message-ID: <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>

 Hi all,

I agree with the recommendations of accepting (1) and rejecting (2) and
(3). The Report here (
https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4)
mentions that defaults are local to a module, and I think this is the right
move, even more so since we can think of other ways of importing/exporting
defaults, like plug-ins.

Alejandro

El 19 may 2021 4:11:48, Eric Seidel <eric at seidel.io> escribió:

> Hi all,
>
> Mario has proposed a handful of language extensions around type defaulting.
>
> 1. NamedDefaults: this extension simply allows specifying the class to
> default, instead of it always being Num (or a handful of other hardcoded
> classes if one enables ExtendedDefaultRules). The rule only applies to the
> current module, as usual.
>
> 2. ExportedDefaults: this extension allows exporting defaulting rules.
>
> 3. ImportedDefaults: this extension makes import declarations pull in
> defaulting rules implicitly, like class instances.
>
> Extensions (2) and (3) work together to provide a mechanism for sharing
> sets of defaulting rules across modules. It is possible to import
> conflicting sets of defaulting rules from different modules, in that case
> the conflict must be resolved manually by the importing module, with a new
> defaulting rule.
>
> My recommendation is that we
>
> * Accept extension (1), as it is a clear improvement over the status quo
> and can stand on its own.
>
> * Reject (without prejudice) extensions (2) and (3). These extensions
> bring considerable extra complexity and another orphan-like mechanism.
> There's an open question here of whether defaulting rules should be
> globally coherent like type classes, or if they're something different; the
> discussion has arguments for both sides. I'm not sure, and so I recommend
> we don't commit ourselves one way or the other for now.
>
> Please take a look at the proposal.
>
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409
> Proposal:
> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
>
> Eric
>
> On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
>
> Dear Committe,
>
>
> Exportable named defaults
>
> has been proposed by Mario
>
> https://github.com/ghc-proposals/ghc-proposals/pull/409
>
>
> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst
>
>
> I propose Eric as the Shepherd.
>
>
> This did not gather a lot of attention on Github, or rather none, so
>
> Eric, maybe also consider whether this needs to be advertised more, or
>
> maybe who should be pointed to it.
>
>
> Please guide us to a conclusion as outlined in
>
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> Thanks,
>
> Joachim
>
> --
>
> --
>
> Joachim Breitner
>
>   mail at joachim-breitner.de
>
>   http://www.joachim-breitner.de/
>
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at haskell.org
>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> 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/20210520/0356ae07/attachment.html>

From arnaud.spiwack at tweag.io  Thu May 20 15:42:30 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 20 May 2021 17:42:30 +0200
Subject: [ghc-steering-committee] #283: Local modules (again),
	recommendation: accept
Message-ID: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>

Dear all,

It is time to review the local modules proposal, from our own Richard
Eisenberg, again. In fact it’s been time for a while, and I must apologise
to Richard for not having understood that. Sorry, Richard.

Link: https://github.com/ghc-proposals/ghc-proposals/pull/283

Since the last time, the proposal has been both simplified and made more
precise. The main issues solved by this proposal are

   - The ability to export qualified names from modules
   - The ability to define functions with qualified names within a module (
   *e.g.* you could have both T.f and U.f).
   - The ability to locally refer to qualified data as unqualified (suppose
   Set.map is in scope, then the proposal lets you write let import module
   Set in map f (map g some_set).

I think these are three important issues, and the proposal makes a good
case that they ought to be solved together. I also think that the
specification is clear and doesn’t leave any dark corner. Caveat: I have
contributed to writing the current specification, so I may be missing some
flaws.

The proposal does introduce a somewhat byzantine semantic difference
between module X and module qualified X in export lists. This is to keep
the current meaning of module X which is already not very intuitive (cf
https://ro-che.info/articles/2012-12-25-haskell-module-system-p1 ). I think
this is unavoidable.

There are also 3 optional pieces of specification that we are asked to rule
on (§4). I’m personally in favour of option 1. I’m weakly in favour of
option 3 (with a preference for the variant described in Alternative 7). On
the other hand option 2 seems to add a bit too much syntactic subtlety to
be worth it (though if we choose option 2, I see no reason not to accept
Alternative 3 as well).

/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210520/915b74f6/attachment.html>

From trupill at gmail.com  Thu May 20 17:35:30 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 20 May 2021 17:35:30 +0000
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <62fa128e-68d2-445c-8197-4f937227e5f5@www.fastmail.com>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
 <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
 <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>
 <AM5PR83MB0353854FDF53142F14315B31AD2B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <62fa128e-68d2-445c-8197-4f937227e5f5@www.fastmail.com>
Message-ID: <CAHnFXOsYtJbzLAtA_BW6t0gVh=GejFKtwr_2zj9FW4WaP_1gOw@mail.gmail.com>

 I’ll join the rest in saying that your work in the committee has been
great, so you’ll be certainly missed.
Thanks for all your work these years!

Alejandro

El 20 may 2021 2:36:40, Eric Seidel <eric at seidel.io> escribió:

> I'll echo everyone else. I've also greatly enjoyed working with you over
> the years, and will miss your arguments for keeping Haskell a simpler
> language.
>
> Thanks Iavor!
>
> Eric
>
> On Wed, May 19, 2021, at 17:24, Simon Peyton Jones via
> ghc-steering-committee wrote:
>
> Iavor
>
>
> I too would like to thank you very much.  You have been a big
>
> contributor to Haskell for a long time, and I've really appreciated
>
> your input to the GHC steering committee.
>
>
> Thank you!
>
>
> Simon
>
>
> |  -----Original Message-----
>
> |  From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On
>
> |  Behalf Of Richard Eisenberg
>
> |  Sent: 19 May 2021 17:22
>
> |  To: Joachim Breitner <mail at joachim-breitner.de>
>
> |  Cc: ghc-steering-committee at haskell.org
>
> |  Subject: Re: [ghc-steering-committee] Stepping down from the committee
>
> |
>
> |  I wholeheartedly agree with Joachim here. I was sad to see Iavor's note
> and
>
> |  contemplating writing a plea to stay on -- but then wanted to respect
> your
>
> |  decision. Despite the fact, Iavor, that you and I often have been on
>
> |  opposing sides of a debate, it's a pleasure to work with you, and I will
>
> |  miss your voice in this committee.
>
> |
>
> |  Thanks for all your contributions!
>
> |
>
> |  Richard
>
> |
>
> |  > On May 19, 2021, at 3:17 AM, Joachim Breitner <
> mail at joachim-breitner.de>
>
> |  wrote:
>
> |  >
>
> |  > Hello Iavor,
>
> |  >
>
> |  > I'm sad to you see leave, and you will leave an hole in the committee.
>
> |  > I have always greatly valued your particular perspective on these
>
> |  > matters, and fear that it will be underrepresented in the committee in
>
> |  > the future. We'll need to keep "what would Iavor say to this" in the
>
> |  > back of our heads from now on...
>
> |  >
>
> |  > 50 months is an impressive time to spend on a project like this, and
>
> |  > if interests shift and it becomes less rewarding than it used to be,
>
> |  > then stepping down is the right step to do. Should you ever change
>
> |  > your mind, I'll be happy to see your name on the ballot!
>
> |  >
>
> |  > Cheers, and looking forward to see you at a conference at some point,
>
> |  > Joachim
>
> |  >
>
> |  >
>
> |  > Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
>
> |  >> I think it is time for me to step down from the GHC committee---
>
> |  >> lately I find that I don't have the enthusiasm I used to have for
>
> |  >> reviewing or discussing proposals, so it makes sense to make space
>
> |  >> for someone who is passionate about doing this work.
>
> |  >>
>
> |  >> Thanks for working with me, and I am looking forward to having a beer
>
> |  >> with you all at ICFP once the world reopens!
>
> |  >>
>
> |  >> -Iavor
>
> |  >> _______________________________________________
>
> |  >> ghc-steering-committee mailing list
>
> |  >> ghc-steering-committee at haskell.org
>
> |  >>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
>
> |  >> l.haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee
>
> |  >> &amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C07a7b89435ee4bb2b68d08d
>
> |  >> 91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63757038144964
>
> |  >> 8409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>
> |  >> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4LEUMtHN%2BS1k7wqTngaJAuq
>
> |  >> WXCG%2BE%2FTRp6f8BG7kzxI%3D&amp;reserved=0
>
> |  > --
>
> |  > Joachim Breitner
>
> |  >  mail at joachim-breitner.de
>
> |  >
>
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
>
> |  > oachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C07a
>
> |  > 7b89435ee4bb2b68d08d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
>
> |  > C0%7C637570381449658400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>
> |  > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=synnK38S
>
> |  > Prg%2BgU0xol0v%2Fu5qakT9cLJ7vLzHm%2FISojk%3D&amp;reserved=0
>
> |  >
>
> |  >
>
> |  > _______________________________________________
>
> |  > ghc-steering-committee mailing list
>
> |  > ghc-steering-committee at haskell.org
>
> |  >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>
> |  > .haskell.org
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
>
> |  > mp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C07a7b89435ee4bb2b68d08d91a
>
> |  > e2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400
>
> |  > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
>
> |  > k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7
>
> |  > l8cw44b4YssI%3D&amp;reserved=0
>
> |
>
> |  _______________________________________________
>
> |  ghc-steering-committee mailing list
>
> |  ghc-steering-committee at haskell.org
>
> |
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
>
> |  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
> %7C07a7b89435ee4bb2b68d0
>
> |
>  8d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400%
>
> |
>  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>
> |
>  LCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7l8cw44b4YssI%
>
> |  3D&amp;reserved=0
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> ghc-steering-committee at haskell.org
>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> 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/20210520/0e544ade/attachment-0001.html>

From marlowsd at gmail.com  Sat May 22 11:31:00 2021
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 22 May 2021 12:31:00 +0100
Subject: [ghc-steering-committee] Stepping down from the committee
In-Reply-To: <CAHnFXOsYtJbzLAtA_BW6t0gVh=GejFKtwr_2zj9FW4WaP_1gOw@mail.gmail.com>
References: <CAGK9nupoFo98Avk+Ets-wzTsUK8+vT4SLO0wBKNZ7oWKWg1L3Q@mail.gmail.com>
 <c2617ac98885ae41074bbf5c89f15ad1cbf05f30.camel@joachim-breitner.de>
 <010f0179856ee556-78ef4c38-3527-4155-b9c7-b36566f63679-000000@us-east-2.amazonses.com>
 <AM5PR83MB0353854FDF53142F14315B31AD2B9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <62fa128e-68d2-445c-8197-4f937227e5f5@www.fastmail.com>
 <CAHnFXOsYtJbzLAtA_BW6t0gVh=GejFKtwr_2zj9FW4WaP_1gOw@mail.gmail.com>
Message-ID: <CANsrgP+dC04+Xx3SqwZPhu05baqSvo-6cpXnxTTV-4vC7NZ_Uw@mail.gmail.com>

Same here! Sad to see you leave Iavor, your contributions will be missed.

Cheers
Siimon

On Thu, 20 May 2021 at 18:36, Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I’ll join the rest in saying that your work in the committee has been
> great, so you’ll be certainly missed.
> Thanks for all your work these years!
>
> Alejandro
>
> El 20 may 2021 2:36:40, Eric Seidel <eric at seidel.io> escribió:
>
>> I'll echo everyone else. I've also greatly enjoyed working with you over
>> the years, and will miss your arguments for keeping Haskell a simpler
>> language.
>>
>> Thanks Iavor!
>>
>> Eric
>>
>> On Wed, May 19, 2021, at 17:24, Simon Peyton Jones via
>> ghc-steering-committee wrote:
>>
>> Iavor
>>
>>
>> I too would like to thank you very much.  You have been a big
>>
>> contributor to Haskell for a long time, and I've really appreciated
>>
>> your input to the GHC steering committee.
>>
>>
>> Thank you!
>>
>>
>> Simon
>>
>>
>> |  -----Original Message-----
>>
>> |  From: ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> On
>>
>> |  Behalf Of Richard Eisenberg
>>
>> |  Sent: 19 May 2021 17:22
>>
>> |  To: Joachim Breitner <mail at joachim-breitner.de>
>>
>> |  Cc: ghc-steering-committee at haskell.org
>>
>> |  Subject: Re: [ghc-steering-committee] Stepping down from the committee
>>
>> |
>>
>> |  I wholeheartedly agree with Joachim here. I was sad to see Iavor's
>> note and
>>
>> |  contemplating writing a plea to stay on -- but then wanted to respect
>> your
>>
>> |  decision. Despite the fact, Iavor, that you and I often have been on
>>
>> |  opposing sides of a debate, it's a pleasure to work with you, and I
>> will
>>
>> |  miss your voice in this committee.
>>
>> |
>>
>> |  Thanks for all your contributions!
>>
>> |
>>
>> |  Richard
>>
>> |
>>
>> |  > On May 19, 2021, at 3:17 AM, Joachim Breitner <
>> mail at joachim-breitner.de>
>>
>> |  wrote:
>>
>> |  >
>>
>> |  > Hello Iavor,
>>
>> |  >
>>
>> |  > I'm sad to you see leave, and you will leave an hole in the
>> committee.
>>
>> |  > I have always greatly valued your particular perspective on these
>>
>> |  > matters, and fear that it will be underrepresented in the committee
>> in
>>
>> |  > the future. We'll need to keep "what would Iavor say to this" in the
>>
>> |  > back of our heads from now on...
>>
>> |  >
>>
>> |  > 50 months is an impressive time to spend on a project like this, and
>>
>> |  > if interests shift and it becomes less rewarding than it used to be,
>>
>> |  > then stepping down is the right step to do. Should you ever change
>>
>> |  > your mind, I'll be happy to see your name on the ballot!
>>
>> |  >
>>
>> |  > Cheers, and looking forward to see you at a conference at some point,
>>
>> |  > Joachim
>>
>> |  >
>>
>> |  >
>>
>> |  > Am Dienstag, den 18.05.2021, 11:52 -0700 schrieb Iavor Diatchki:
>>
>> |  >> I think it is time for me to step down from the GHC committee---
>>
>> |  >> lately I find that I don't have the enthusiasm I used to have for
>>
>> |  >> reviewing or discussing proposals, so it makes sense to make space
>>
>> |  >> for someone who is passionate about doing this work.
>>
>> |  >>
>>
>> |  >> Thanks for working with me, and I am looking forward to having a
>> beer
>>
>> |  >> with you all at ICFP once the world reopens!
>>
>> |  >>
>>
>> |  >> -Iavor
>>
>> |  >> _______________________________________________
>>
>> |  >> ghc-steering-committee mailing list
>>
>> |  >> ghc-steering-committee at haskell.org
>>
>> |  >>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai
>>
>> |  >> l.haskell.org
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee
>>
>> |  >> &amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C07a7b89435ee4bb2b68d08d
>>
>> |  >>
>> 91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63757038144964
>>
>> |  >>
>> 8409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
>>
>> |  >>
>> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4LEUMtHN%2BS1k7wqTngaJAuq
>>
>> |  >> WXCG%2BE%2FTRp6f8BG7kzxI%3D&amp;reserved=0
>>
>> |  > --
>>
>> |  > Joachim Breitner
>>
>> |  >  mail at joachim-breitner.de
>>
>> |  >
>>
>> |  >
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
>>
>> |  > oachim-breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C07a
>>
>> |  >
>> 7b89435ee4bb2b68d08d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
>>
>> |  >
>> C0%7C637570381449658400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>>
>> |  >
>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=synnK38S
>>
>> |  > Prg%2BgU0xol0v%2Fu5qakT9cLJ7vLzHm%2FISojk%3D&amp;reserved=0
>>
>> |  >
>>
>> |  >
>>
>> |  > _______________________________________________
>>
>> |  > ghc-steering-committee mailing list
>>
>> |  > ghc-steering-committee at haskell.org
>>
>> |  >
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>>
>> |  > .haskell.org
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
>>
>> |  > mp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C07a7b89435ee4bb2b68d08d91a
>>
>> |  >
>> e2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400
>>
>> |  >
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
>>
>> |  >
>> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7
>>
>> |  > l8cw44b4YssI%3D&amp;reserved=0
>>
>> |
>>
>> |  _______________________________________________
>>
>> |  ghc-steering-committee mailing list
>>
>> |  ghc-steering-committee at haskell.org
>>
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske
>>
>> |  ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>
>> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7C07a7b89435ee4bb2b68d0
>>
>> |
>>  8d91ae2418e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637570381449658400%
>>
>> |
>>  7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>>
>> |
>>  LCJXVCI6Mn0%3D%7C3000&amp;sdata=2M7W3brh3I43lwVtZcrTXcJwNnc3eE7l8cw44b4YssI%
>>
>> |  3D&amp;reserved=0
>>
>> _______________________________________________
>>
>> ghc-steering-committee mailing list
>>
>> ghc-steering-committee at haskell.org
>>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20210522/f1453985/attachment.html>

From eric at seidel.io  Tue May 25 00:38:18 2021
From: eric at seidel.io (Eric Seidel)
Date: Mon, 24 May 2021 20:38:18 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Recommendation_for_=23378=3A_s?=
 =?utf-8?q?upport_the_design_for_dependent_types?=
In-Reply-To: <d565c61bf6a9b8ca6972083e5371d4e8dec22f5e.camel@joachim-breitner.de>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <31bd8058-baa8-47e1-84bf-ad4f3fd9a74b@www.fastmail.com>
 <d565c61bf6a9b8ca6972083e5371d4e8dec22f5e.camel@joachim-breitner.de>
Message-ID: <b1ca8744-54dc-4c6a-b62f-7fdc3a32bf10@www.fastmail.com>

On Thu, May 20, 2021, at 02:58, Joachim Breitner wrote:
> I am actually not opposed to compromising on the OIP, and would not
> mind seeing new features of Haskell be used in basic libraries where
> they make sense.
> 
> Base has `HasCallStack`. It has Rank2Polymorphism. It has type
> equalities. It has generics, and thus associated types.

But they're all used judiciously. By and large, you do not need to understand any of these features to use `base` productively. And where they would bleed out too much, we have taken steps to hide the details. For example, when ($) became levity polymorphic, we suppressed runtime representations from GHC's output to avoid confusing less advanced users. 

`HasCallStack` is another interesting case. It's behavior is pretty straightforward but is implemented in terms of a very niche feature, ImplicitParams. The underlying representation is exposed in this case, but we did discuss whether we should prefer to make it abstract and just reuse the ImplicitParams machinery inside GHC. We didn't do that, but perhaps we should have.

From trupill at gmail.com  Tue May 25 19:09:20 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Tue, 25 May 2021 19:09:20 +0000
Subject: [ghc-steering-committee] #283: Local modules (again),
 recommendation: accept
In-Reply-To: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>
References: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>
Message-ID: <CAHnFXOvrnCDvMKEQqSWL0R2ttXRqyyRSnTxzF-QnzbpUpDhe5g@mail.gmail.com>

 Dear all,

I am in favor of this proposal. I think it solves one important issue in
Haskell’s design (I’ve always hated the 1-1 relationship between modules
and files), and does so in a way which feels natural with the rest of the
language.

Regarding the optional pieces of the spec:
- I am not sure of the benefit of allowing (1), compared with the possible
surprise of users.
- I do not fully understand (2).
- I think (3) would be great, if we ensure that nothing changes if I don’t
use “qualified”, even if -XLocalModules is on.

Regards,
Alejandro

El 20 may 2021 17:42:30, Spiwack, Arnaud <arnaud.spiwack at tweag.io> escribió:

> Dear all,
>
> It is time to review the local modules proposal, from our own Richard
> Eisenberg, again. In fact it’s been time for a while, and I must apologise
> to Richard for not having understood that. Sorry, Richard.
>
> Link: https://github.com/ghc-proposals/ghc-proposals/pull/283
>
> Since the last time, the proposal has been both simplified and made more
> precise. The main issues solved by this proposal are
>
>    - The ability to export qualified names from modules
>    - The ability to define functions with qualified names within a module
>    (*e.g.* you could have both T.f and U.f).
>    - The ability to locally refer to qualified data as unqualified
>    (suppose Set.map is in scope, then the proposal lets you write let
>    import module Set in map f (map g some_set).
>
> I think these are three important issues, and the proposal makes a good
> case that they ought to be solved together. I also think that the
> specification is clear and doesn’t leave any dark corner. Caveat: I have
> contributed to writing the current specification, so I may be missing some
> flaws.
>
> The proposal does introduce a somewhat byzantine semantic difference
> between module X and module qualified X in export lists. This is to keep
> the current meaning of module X which is already not very intuitive (cf
> https://ro-che.info/articles/2012-12-25-haskell-module-system-p1 ). I
> think this is unavoidable.
>
> There are also 3 optional pieces of specification that we are asked to
> rule on (§4). I’m personally in favour of option 1. I’m weakly in favour of
> option 3 (with a preference for the variant described in Alternative 7). On
> the other hand option 2 seems to add a bit too much syntactic subtlety to
> be worth it (though if we choose option 2, I see no reason not to accept
> Alternative 3 as well).
>
> /Arnaud
> _______________________________________________
> 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/20210525/97aa133c/attachment.html>

From rae at richarde.dev  Tue May 25 20:01:34 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 25 May 2021 20:01:34 +0000
Subject: [ghc-steering-committee] #409: Exportable named defaults,
 Recommendation: Partial Accept
In-Reply-To: <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
References: <fc9e6b7d6e03228bf5a4badfb7748eee0c8b1b16.camel@joachim-breitner.de>
 <ddf47700-eb3c-4585-8291-4dad0d7e62a8@www.fastmail.com>
 <CAHnFXOuXc6K0ijRbRh+ZY8TkJToZ93Fur1=EOgfvPvWpP3GVGw@mail.gmail.com>
Message-ID: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com>

I have commented on GitHub with my thoughts here: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-848221001 <https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-848221001>

Thanks,
Richard

> On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> Hi all,
> 
> I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here (https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4 <https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4>) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.
> 
> Alejandro
> 
> El 19 may 2021 4:11:48, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> escribió:
> Hi all,
> 
> Mario has proposed a handful of language extensions around type defaulting.
> 
> 1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.
> 
> 2. ExportedDefaults: this extension allows exporting defaulting rules.
> 
> 3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.
> 
> Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.
> 
> My recommendation is that we
> 
> * Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.
> 
> * Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. 
> 
> Please take a look at the proposal.
> 
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409 <https://github.com/ghc-proposals/ghc-proposals/pull/409>
> Proposal: https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst <https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst>
> 
> Eric
> 
> On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
>> Dear Committe,
>> 
>> Exportable named defaults
>> has been proposed by Mario
>> https://github.com/ghc-proposals/ghc-proposals/pull/409 <https://github.com/ghc-proposals/ghc-proposals/pull/409>
>> https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst <https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst>
>> 
>> I propose Eric as the Shepherd.
>> 
>> This did not gather a lot of attention on Github, or rather none, so
>> Eric, maybe also consider whether this needs to be advertised more, or
>> maybe who should be pointed to it.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> 
>> Thanks,
>> Joachim
>> -- 
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> 
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/20210525/4daa73e2/attachment-0001.html>

From rae at richarde.dev  Tue May 25 21:54:38 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 25 May 2021 21:54:38 +0000
Subject: [ghc-steering-committee] #283: Local modules (again),
 recommendation: accept
In-Reply-To: <CAHnFXOvrnCDvMKEQqSWL0R2ttXRqyyRSnTxzF-QnzbpUpDhe5g@mail.gmail.com>
References: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>
 <CAHnFXOvrnCDvMKEQqSWL0R2ttXRqyyRSnTxzF-QnzbpUpDhe5g@mail.gmail.com>
Message-ID: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com>



> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> - I am not sure of the benefit of allowing (1), compared with the possible surprise of users.
> - I do not fully understand (2).
> - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on.

If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm.

I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble:

> import Data.Set as Set ( abcde )
> 
> data Set = Mk { abcdf :: Int }
> 
> blah = Set.abcdf

Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error.

Here's another case:

> import Data.Set as Set ( Set )
> 
> data Set = Mk
> 
> x :: Set.Set

Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name.

Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites.

I, too, could live without (2).

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210525/5e433eff/attachment.html>

From simonpj at microsoft.com  Wed May 26 07:20:32 2021
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 26 May 2021 07:20:32 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
	design for dependent types
In-Reply-To: <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <AM5PR83MB0353FD7665B7930E66C460A0AD249@AM5PR83MB0353.EURPRD83.prod.outlook.com>

I have since heard from Tom, Eric, and Arnaud; and Iavor has stepped down from the committee.  So we have

  *   Support: Tom, Eric, Arnaud, Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
  *   Against: no one
That leaves: Cale and Simon M.
At this point I think we have enough support to declare the proposal accepted.
Joachim, can you merge it?
Thanks
Simon

From: Simon Peyton Jones <simonpj at microsoft.com>
Sent: 13 May 2021 16:09
To: ghc-steering-committee at haskell.org
Cc: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: Recommendation for #378: support the design for dependent types

Friends
You have now had a month to review my recommendation below, to accept #378: support for dependent types. Here it is once more<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493133964%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QjIYtMwzGAKby2bqezO9AmUchHO9zUyGhzSOCJPlTms%3D&reserved=0>
I have heard

  *   Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)
  *   Against: no one
But that leaves Tom, Eric, Arnaud, Cale, Simon M, and Iavor who have not expressed an opinion.  Please do!
Failing further feedback, I'll accept on Tuesday next week.
There has been some further discussion on the pull request<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493143963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lOdCJyt61%2B6elYx1npgMG9BBsrHD1FHg%2BFo0IbylndM%3D&reserved=0>, but I don't think any fundamentally new points have come up.  This is clearly a judgement call, but one I think we should make.  Haskell has always been a research lab - that's part of what makes it distinctive.  I think we can continue to celebrate that innovation.  But see my email immediately below for what we are and are not accepting.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Sent: 15 April 2021 10:39
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Subject: Recommendation for #378: support the design for dependent types

Dear GHC steering committee
OK Richard has now revised the "Design for Dependent Types" proposal, and has resubmitted it.  As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it.
Here it is once more<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493143963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wTdlzqgSiFRe5hwoaHG2s6ukIv2eAaEY1M%2F%2FbDxrRII%3D&reserved=0>
I propose acceptance.
Remember:

  *   We would not be accepting every detail of the design in Section 4 - rather, we expect further specific proposals as we move in the direction described in the proposal.   So we should not debate the fine print of Section 4.
  *   We would be accepting that the proposal describes a direction of travel that we are happy with.  That in turn gives people the confidence to invest efforts in those more detailed proposals.  As the "Proposed change specification" says:  "When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features."
Any views?   Questions of clarification or technical questions belong on the comment stream.
Thanks
Simon
From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Simon Peyton Jones via ghc-steering-committee
Sent: 06 April 2021 13:58
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types

Richard and I have discussed this.
We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493153956%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MxflQbPVLwdC0uGcrJ7P%2FkZzsqIgt1vo%2BPfExxjYkS4%3D&reserved=0>.  Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail.
Simon

From: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Sent: 29 March 2021 13:17
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Subject: Recommendation for #378: support the design for dependent types

Dear GHC Steering Committee
I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493163947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VBTZfqvQ8fEISn39rMwYV0zc6uXV8g07l8y4aZ0WcAI%3D&reserved=0>
As you'll see, there is a lot of useful context, but the payload is pretty simple

When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493163947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qoyKKGDL%2Fz6JMu%2FC3SMBmjnC24KJFic1i57iG7AG8hY%3D&reserved=0>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features.

Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.

See also the committee's Review Criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7C7e737205b1e3428cc18208d916210e74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637565153493173941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bz9L49gK5qLs5RArmLvfcOS7GfdMY3FyJm5cthB%2BFI8%3D&reserved=0>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.

Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever.
Any views?  Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210526/256bc17d/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed May 26 07:28:02 2021
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 26 May 2021 09:28:02 +0200
Subject: [ghc-steering-committee] #283: Local modules (again),
 recommendation: accept
In-Reply-To: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com>
References: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>
 <CAHnFXOvrnCDvMKEQqSWL0R2ttXRqyyRSnTxzF-QnzbpUpDhe5g@mail.gmail.com>
 <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQmBm8pHzHdOGTT=SjYRZmb4EgwfCMDq6Prz6deDqsH8Pg@mail.gmail.com>

I'm realising that I inverted additional options 1 and 3 in my reply. To
spell things out: I'm in favour of the namespace introduced for every
datatype and such; and weakly in favour of anonymous modules, for which I
prefer the `_` syntax than simply omitting the name.

On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> - I am not sure of the benefit of allowing (1), compared with the possible
> surprise of users.
> - I do not fully understand (2).
> - I think (3) would be great, if we ensure that nothing changes if I don’t
> use “qualified”, even if -XLocalModules is on.
>
>
> If in the language, I would use (1) -- anonymous local modules --
> regularly, when defining a function or class instance with a bunch of
> "local" helper functions. Of course, if we can't omit the module name, I
> will suffer no great harm.
>
> I cannot offer the guarantee you seek in (3), but I don't think you want
> it. (If nothing changes, then the feature has no effect!) Here is a
> scenario where (3) could cause trouble:
>
> import Data.Set as Set ( abcde )
>
> data Set = Mk { abcdf :: Int }
>
> blah = Set.abcdf
>
>
> Previously, GHC would have suggested that you perhaps misspelled abcde.
> Now, you'll get (presumably) a type error.
>
> Here's another case:
>
> import Data.Set as Set ( Set )
>
> data Set = Mk
>
> x :: Set.Set
>
>
> Everything is happy today, but with -XLocalModules (and (3)), the type of
> x is an ambiguous name.
>
> Any example that causes trouble, though, will have something in common: an
> imported module name (possibly via an alias) that matches a locally defined
> type name. I would imagine this pattern is rare in practice, and that the
> benefit of (3) would outweigh the number of times that a problem like this
> bites.
>
> I, too, could live without (2).
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210526/d64ccb28/attachment.html>

From mail at joachim-breitner.de  Wed May 26 07:38:55 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 26 May 2021 09:38:55 +0200
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <AM5PR83MB0353FD7665B7930E66C460A0AD249@AM5PR83MB0353.EURPRD83.prod.outlook.com>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353FD7665B7930E66C460A0AD249@AM5PR83MB0353.EURPRD83.prod.outlook.com>
Message-ID: <a906b4d7819c8d83573814fb322c97e762b92b5a.camel@joachim-breitner.de>

Am Mittwoch, den 26.05.2021, 07:20 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> At this point I think we have enough support to declare the proposal accepted.
> Joachim, can you merge it?

Done!
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Wed May 26 09:24:39 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 26 May 2021 11:24:39 +0200
Subject: [ghc-steering-committee] Please review #281: Visible 'forall' in
 types of terms, Shepherd: Richard
Message-ID: <f8fdac40ad95ac6c85a25a5fab2bd94e48d76f3f.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Visible 'forall' in types of terms
has been proposed by Vladislav
https://github.com/ghc-proposals/ghc-proposals/pull/281
https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst

This was just resubmitted, given that #378 was accepted. The previous
shepherd was Iavor; I am suggesting Richard as the new shepherd, as he
was heavily involved in the Github thread already.


Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Wed May 26 12:32:25 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 26 May 2021 12:32:25 +0000
Subject: [ghc-steering-committee] Recommendation for #378: support the
 design for dependent types
In-Reply-To: <a906b4d7819c8d83573814fb322c97e762b92b5a.camel@joachim-breitner.de>
References: <AM5PR83MB0353A993C0D1D3AC5E18EB16AD4D9@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353B1F600EF5F2FD16D755DAD519@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <AM5PR83MB0353FD7665B7930E66C460A0AD249@AM5PR83MB0353.EURPRD83.prod.outlook.com>
 <a906b4d7819c8d83573814fb322c97e762b92b5a.camel@joachim-breitner.de>
Message-ID: <010f0179a8a96a39-21be0d02-9fb1-4443-a5d2-010c25595dbf-000000@us-east-2.amazonses.com>

Thanks, all! :)

I think the ability to write up (collaboratively with Simon) and discuss a proposal such as this one publicly really shows the virtue of the proposal process. Thanks for all the feedback here!

Richard

> On May 26, 2021, at 3:38 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Am Mittwoch, den 26.05.2021, 07:20 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
>> At this point I think we have enough support to declare the proposal accepted.
>> Joachim, can you merge it?
> 
> Done!
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From bravit111 at gmail.com  Wed May 26 12:32:52 2021
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Wed, 26 May 2021 15:32:52 +0300
Subject: [ghc-steering-committee] #351: NoIncomplete, rec: accept
Message-ID: <CALpVSmNSgaA3fTh8LA75_mxW_0r5mNUzZAN7F6L3kG1ZA-t_iQ@mail.gmail.com>

Dear Committee,

We have been discussing the NoIncomplete pragma proposal by John Ericson
for quite a long time. I think it's ready for acceptance.

The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351
The rendered version:
https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst

The proposal aims to introduce the NoIncomplete pragma that would prohibit
programs which have a source of incompleteness (in patterns, in methods) in
them. There is also the new -fdefer-incompleteness-errors flag.

I think this feature comes quite handy in education. I'd use it all the
time with my students.

Please comment here or in the GitHub thread if you see any problems with
this proposal.

Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210526/3dfe4f70/attachment.html>

From rae at richarde.dev  Wed May 26 12:35:26 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 26 May 2021 12:35:26 +0000
Subject: [ghc-steering-committee] #283: Local modules (again),
 recommendation: accept
In-Reply-To: <CAH6fHQmBm8pHzHdOGTT=SjYRZmb4EgwfCMDq6Prz6deDqsH8Pg@mail.gmail.com>
References: <CAH6fHQmnJV_nNN7g3qjq5LMQMDot8cbYfgT5xp_udkNQ3T=oTA@mail.gmail.com>
 <CAHnFXOvrnCDvMKEQqSWL0R2ttXRqyyRSnTxzF-QnzbpUpDhe5g@mail.gmail.com>
 <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com>
 <CAH6fHQmBm8pHzHdOGTT=SjYRZmb4EgwfCMDq6Prz6deDqsH8Pg@mail.gmail.com>
Message-ID: <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com>



> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name.

Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent.

Richard

> 
> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> 
>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> wrote:
>> 
>> - I am not sure of the benefit of allowing (1), compared with the possible surprise of users.
>> - I do not fully understand (2).
>> - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on.
> 
> If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm.
> 
> I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble:
> 
>> import Data.Set as Set ( abcde )
>> 
>> data Set = Mk { abcdf :: Int }
>> 
>> blah = Set.abcdf
> 
> Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error.
> 
> Here's another case:
> 
>> import Data.Set as Set ( Set )
>> 
>> data Set = Mk
>> 
>> x :: Set.Set
> 
> Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name.
> 
> Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites.
> 
> I, too, could live without (2).
> 
> Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210526/6773b42a/attachment.html>

From rae at richarde.dev  Thu May 27 13:55:33 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 27 May 2021 13:55:33 +0000
Subject: [ghc-steering-committee] #351: NoIncomplete, rec: accept
In-Reply-To: <CALpVSmNSgaA3fTh8LA75_mxW_0r5mNUzZAN7F6L3kG1ZA-t_iQ@mail.gmail.com>
References: <CALpVSmNSgaA3fTh8LA75_mxW_0r5mNUzZAN7F6L3kG1ZA-t_iQ@mail.gmail.com>
Message-ID: <010f0179ae1be2a7-1c4798bd-bf34-43ad-9e0d-6a44d17deaac-000000@us-east-2.amazonses.com>

Thanks for putting this forward, Vitaly.

I'm quite strongly against the proposal in its current form, as I've posted on the thread: https://github.com/ghc-proposals/ghc-proposals/pull/351#issuecomment-849654517 <https://github.com/ghc-proposals/ghc-proposals/pull/351#issuecomment-849654517>  But I'd like to see it get into shape into something that could be accepted, as I agree with the motivation here (and would similarly use this in practice).

Richard

> On May 26, 2021, at 8:32 AM, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Dear Committee, 
> 
> We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance.
> 
> The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351 <https://github.com/ghc-proposals/ghc-proposals/pull/351>
> The rendered version: https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst <https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst>
> 
> The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag.
> 
> I think this feature comes quite handy in education. I'd use it all the time with my students.
> 
> Please comment here or in the GitHub thread if you see any problems with this proposal.
> 
> Vitaly
> 
> _______________________________________________
> 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/20210527/3201bf03/attachment.html>

From rae at richarde.dev  Thu May 27 20:19:11 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 27 May 2021 20:19:11 +0000
Subject: [ghc-steering-committee] Please review #281: Visible 'forall'
 in types of terms, Shepherd: Richard
In-Reply-To: <f8fdac40ad95ac6c85a25a5fab2bd94e48d76f3f.camel@joachim-breitner.de>
References: <f8fdac40ad95ac6c85a25a5fab2bd94e48d76f3f.camel@joachim-breitner.de>
Message-ID: <010f0179af7b1acd-0ed55d3a-ac26-4669-9319-91a6dcd4142b-000000@us-east-2.amazonses.com>

I have recommended a few clarifications to the proposal text. Will make a more formal recommendation here once that is done.

Richard

> On May 26, 2021, at 5:24 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Visible 'forall' in types of terms
> has been proposed by Vladislav
> https://github.com/ghc-proposals/ghc-proposals/pull/281
> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst
> 
> This was just resubmitted, given that #378 was accepted. The previous
> shepherd was Iavor; I am suggesting Richard as the new shepherd, as he
> was heavily involved in the Github thread already.
> 
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From rae at richarde.dev  Fri May 28 18:49:26 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 28 May 2021 18:49:26 +0000
Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms;
	rec: accept
Message-ID: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com>

Hi committee,

Proposal #281 has been submitted for our consideration.

Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://github.com/ghc-proposals/ghc-proposals/pull/281>
Proposal text: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst>

The text of the proposal is long and detailed, but do not be daunted: it is simpler in practice than it appears.

The main payload of the proposal is: Introduce a new extension -XRequiredTypeArguments. With this extension enabled, the `forall ... ->` syntax, currently in existence in kinds, is now available in types (of ordinary functions). This means that function definitions and call sites are sometimes required to write a type argument. The type argument is *not* preceded by @ or any other syntactic marker.

This is useful for defining what would otherwise be ambiguous types. Example:

> sizeof :: forall a -> Sizeable a => Int
> sizeof = ...
> 
> intWidth = sizeof Int

There are further examples and motivation in the proposal.

The rest of the proposal is simply about dealing with odd corner cases that come up with the main payload. In particular, mixing types in with terms with no syntactic signifier means that we must be careful about parsing and namespaces. If a type argument is written in the syntax that is shared between types and terms (including function application!) and uses identifiers in scope in only one of the two namespaces, nothing unusual can be observed. But, of course, there are corner cases. Here are some of the salient details:
- Define type-syntax and term-syntax, where the choice of syntax is always driven by syntactic markers, such as :: or @. See the dependent types proposal <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#lexical-scoping-term-syntax-and-type-syntax-and-renaming> for more details. Parsing and name-resolution are controlled by whether a phrase is in type-syntax or term-syntax. For name resolution, if a lookup fails in the first namespace (the term-level namespace in term-syntax or the type-level namespace in type-syntax), we try the other namespace before failing.
- Because term- vs type-syntax is controlled by syntax, a required type argument is in *term*-syntax and gets name-resolved *as a term*. In the absence of punning, this works out fine, but it is possible that a punned identifier will cause confusion. The proposal includes section 4.3 allowing users to write `type` to signify a switch to type-syntax.
- The proposal also includes a way to avoid punning for the built-in types with privileged syntax: lists and tuples. This method allows users to specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in types (but still allows it for terms). The proposal also suggests exporting type List = [] from Data.List and other synonyms for tuples from Data.Tuple.

---------------

I recommend acceptance. When doing type-level programming, the lack of this feature is strange, leading to ambiguous types and easy-to-forget arguments and easy-to-make type errors. The design space here is difficult, but this proposal is very much in keeping with the design sketch of our recently-accepted #378, in particular its section on this point <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#dependent-application-and-the-static-subset>. I believe the design described here is both backward compatible with what we have today (users who do not use this feature will not notice a difference) and forward compatible with a cohesive design for dependent types.

There are several optional pieces:
- The `type` herald <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-type-herald>. I am unsure about this one, but others have felt strongly in favor, and I have no reason to object.
- Types-in-terms <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-types-in-terms>. I think this is necessary in order to avoid annoying definitions of type synonyms for one-off usage sites. It is a straightforward extension of the term-level parser to allow previously type-level-only constructs. It is necessary in order for us to achieve the vision of dependent types in #378. The only challenge here is that this requires us to make `forall` an unconditional keyword in terms. This does pose a backward-compatibility problem. I see, for example, that the sbv package exports a function named `forall`, so we may need to think more carefully about how to proceed here -- possibly by guarding the keyword-ness of `forall` behind the extension for some number of transitionary releases.
- Lists and Tuples <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-lists-and-tuples>. This section describes the -XNoListTupleTypeSyntax extension. I am not convinced that this change needs to be part of this proposal (thinking it belongs more in #270), but I do think we'll need it in the end. Is it OK to export new type synonyms from Data.List and Data.Tuple? Not sure, though I'd like these exported from some central place.

What do others think?

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210528/45a98c6e/attachment.html>

From marlowsd at gmail.com  Sat May 29 11:15:28 2021
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 29 May 2021 12:15:28 +0100
Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in
 terms; rec: accept
In-Reply-To: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com>
References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgP+S2dTYyw-h_bfq2-48A76dU6XDBs3UKbGFn+hoPJnCow@mail.gmail.com>

I support the goal of this proposal; indeed I would immediately use it in
several places that I can think of off the top of my head.

But the name resolution aspects concern me. I forsee a lot of confusion if
we can't write `[Int]` as a type argument with the usual meaning. The error
message is likely to be super confusing if it has to talk about the
difference between a promoted list type and the usual list type
constructor, which have the same syntax. I'm not a fan of having to write
`List Int` when it's a visible type argument, but `[Int]` everywhere else.

Would it be possible to require the leading quote to get the promoted
meaning, otherwise defaulting to the usual meaning of `[Int]`?

Also could we defer name resolution until type checking for things like
`Proxy`, so that the obvious thing doesn't require namespace gymnastics?

Cheers
Simon

On Fri, 28 May 2021 at 19:49, Richard Eisenberg <rae at richarde.dev> wrote:

> Hi committee,
>
> Proposal #281 has been submitted for our consideration.
>
> Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281
> Proposal text:
> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst
>
> The text of the proposal is long and detailed, but do not be daunted: it
> is simpler in practice than it appears.
>
> The main payload of the proposal is: Introduce a new extension
> -XRequiredTypeArguments. With this extension enabled, the `forall ... ->`
> syntax, currently in existence in kinds, is now available in types (of
> ordinary functions). This means that function definitions and call sites
> are sometimes required to write a type argument. The type argument is *not*
> preceded by @ or any other syntactic marker.
>
> This is useful for defining what would otherwise be ambiguous types.
> Example:
>
> sizeof :: forall a -> Sizeable a => Int
> sizeof = ...
>
> intWidth = sizeof Int
>
>
> There are further examples and motivation in the proposal.
>
> The rest of the proposal is simply about dealing with odd corner cases
> that come up with the main payload. In particular, mixing types in with
> terms with no syntactic signifier means that we must be careful about
> parsing and namespaces. If a type argument is written in the syntax that is
> shared between types and terms (including function application!) and uses
> identifiers in scope in only one of the two namespaces, nothing unusual can
> be observed. But, of course, there are corner cases. Here are some of the
> salient details:
> - Define type-syntax and term-syntax, where the choice of syntax is always
> driven by syntactic markers, such as :: or @. See the dependent types
> proposal
> <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#lexical-scoping-term-syntax-and-type-syntax-and-renaming> for
> more details. Parsing and name-resolution are controlled by whether a
> phrase is in type-syntax or term-syntax. For name resolution, if a lookup
> fails in the first namespace (the term-level namespace in term-syntax or
> the type-level namespace in type-syntax), we try the other namespace before
> failing.
> - Because term- vs type-syntax is controlled by syntax, a required type
> argument is in *term*-syntax and gets name-resolved *as a term*. In the
> absence of punning, this works out fine, but it is possible that a punned
> identifier will cause confusion. The proposal includes section 4.3 allowing
> users to write `type` to signify a switch to type-syntax.
> - The proposal also includes a way to avoid punning for the built-in types
> with privileged syntax: lists and tuples. This method allows users to
> specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in
> types (but still allows it for terms). The proposal also suggests exporting
> type List = [] from Data.List and other synonyms for tuples from Data.Tuple.
>
> ---------------
>
> I recommend acceptance. When doing type-level programming, the lack of
> this feature is strange, leading to ambiguous types and easy-to-forget
> arguments and easy-to-make type errors. The design space here is difficult,
> but this proposal is very much in keeping with the design sketch of our
> recently-accepted #378, in particular its section on this point
> <https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/0000-dependent-type-design.rst#dependent-application-and-the-static-subset>.
> I believe the design described here is both backward compatible with what
> we have today (users who do not use this feature will not notice a
> difference) and forward compatible with a cohesive design for dependent
> types.
>
> There are several optional pieces:
> - The `type` herald
> <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-type-herald>.
> I am unsure about this one, but others have felt strongly in favor, and I
> have no reason to object.
> - Types-in-terms
> <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-types-in-terms>.
> I think this is necessary in order to avoid annoying definitions of type
> synonyms for one-off usage sites. It is a straightforward extension of the
> term-level parser to allow previously type-level-only constructs. It is
> necessary in order for us to achieve the vision of dependent types in #378.
> The only challenge here is that this requires us to make `forall` an
> unconditional keyword in terms. This does pose a backward-compatibility
> problem. I see, for example, that the sbv package exports a function named
> `forall`, so we may need to think more carefully about how to proceed here
> -- possibly by guarding the keyword-ness of `forall` behind the extension
> for some number of transitionary releases.
> - Lists and Tuples
> <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst#secondary-change-lists-and-tuples>.
> This section describes the -XNoListTupleTypeSyntax extension. I am not
> convinced that this change needs to be part of this proposal (thinking it
> belongs more in #270), but I do think we'll need it in the end. Is it OK to
> export new type synonyms from Data.List and Data.Tuple? Not sure, though
> I'd like these exported from some central place.
>
> What do others think?
>
> Thanks,
> 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/20210529/b767ca86/attachment-0001.html>

From marlowsd at gmail.com  Sat May 29 11:31:13 2021
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 29 May 2021 12:31:13 +0100
Subject: [ghc-steering-committee] #351: NoIncomplete, rec: accept
In-Reply-To: <CALpVSmNSgaA3fTh8LA75_mxW_0r5mNUzZAN7F6L3kG1ZA-t_iQ@mail.gmail.com>
References: <CALpVSmNSgaA3fTh8LA75_mxW_0r5mNUzZAN7F6L3kG1ZA-t_iQ@mail.gmail.com>
Message-ID: <CANsrgP+wti-zbgc_V18XD58fx5rkU3+wCxGQFUk=_z8O221fZA@mail.gmail.com>

I would support this, but only if
1. we specify precisely exactly which pattern matches are accepted, and
2. GHC accepts only those patterns when NoIncomplete is enabled

That is, it would certainly be a subset of -Wincomplete-patterns. No
cleverness, no adding extra magic to accept more programs with each
release. The point of a spec is to say exactly which programs are accepted,
in such a way that different implementations can implement the feature
consistently - one implementation is not allowed to accept more programs,
otherwise there's no point in having a definition of the feature.

If we don't want to do this (and I suspect it would be annoying to
implement), then I think -Werror is the best alternative.

Cheers
Simon

On Wed, 26 May 2021 at 13:33, Vitaly Bragilevsky <bravit111 at gmail.com>
wrote:

> Dear Committee,
>
> We have been discussing the NoIncomplete pragma proposal by John Ericson
> for quite a long time. I think it's ready for acceptance.
>
> The proposal itself:
> https://github.com/ghc-proposals/ghc-proposals/pull/351
> The rendered version:
> https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst
>
> The proposal aims to introduce the NoIncomplete pragma that would prohibit
> programs which have a source of incompleteness (in patterns, in methods) in
> them. There is also the new -fdefer-incompleteness-errors flag.
>
> I think this feature comes quite handy in education. I'd use it all the
> time with my students.
>
> Please comment here or in the GitHub thread if you see any problems with
> this proposal.
>
> Vitaly
>
> _______________________________________________
> 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/20210529/9356b202/attachment.html>

From vlad.z.4096 at gmail.com  Sat May 29 13:19:10 2021
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Sat, 29 May 2021 16:19:10 +0300
Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in
 terms; rec: accept
In-Reply-To: <CANsrgP+S2dTYyw-h_bfq2-48A76dU6XDBs3UKbGFn+hoPJnCow@mail.gmail.com>
References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com>
 <CANsrgP+S2dTYyw-h_bfq2-48A76dU6XDBs3UKbGFn+hoPJnCow@mail.gmail.com>
Message-ID: <6288B96E-9699-4CDC-BF1E-112BA952D4EE@gmail.com>

Both of your suggestions (regarding lists and regarding Proxy) seem to require type information in order to resolve the meaning of an expression. Given `f e`, I’m assuming you want to parse/rename ‘e’ as an expression if ‘f’ is an ordinary function, and as a type if `f :: forall a -> …`.

However, that would violate the Lexical Scoping Principle described in section 4.3.1 of the "Design for Dependent Types” proposal (#378), which states: "For every occurrence of an identifier, it is possible to uniquely identify its binding site, without involving the type system.”

This principle is useful both in the implementation (it enables a clear delineation between renaming/typechecking) and when reasoning about programs. While it’s possible to violate it, I believe that writing `f (List Int)` is the lesser evil. Also, I don’t think that you’d need to "write `List Int` when it's a visible type argument, but `[Int]` everywhere else”. If consistency is an explicit goal, one can write `List Int` everywhere.

- Vlad

> On 29 May 2021, at 14:15, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I support the goal of this proposal; indeed I would immediately use it in several places that I can think of off the top of my head.
> 
> But the name resolution aspects concern me. I forsee a lot of confusion if we can't write `[Int]` as a type argument with the usual meaning. The error message is likely to be super confusing if it has to talk about the difference between a promoted list type and the usual list type constructor, which have the same syntax. I'm not a fan of having to write `List Int` when it's a visible type argument, but `[Int]` everywhere else.
> 
> Would it be possible to require the leading quote to get the promoted meaning, otherwise defaulting to the usual meaning of `[Int]`?
> 
> Also could we defer name resolution until type checking for things like `Proxy`, so that the obvious thing doesn't require namespace gymnastics?
> 
> Cheers
> Simon
> 
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee