There has been a broad further discussion. What we advertise is that, rather that leave a proposal "under committee review", we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That's different to reject... it means that there is an ongoing debate so it's not a good time for the committee to make a decision. Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 18 February 2021 16:47 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Status On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal. I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this. Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up. -Iavor On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, another status update, because why not. A small reminder: These mails have two sections, one that's a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake). So here's the delta since last month. * GHC2021 defined! Yay! * Bylaws merged! Yay * Simon², Iavor, Richard and me had thus their terms expired. The Simons, as key members, wanted to continue and were voted back in. The others are now "expiring", until the next nomination round concludes. Alejandro is going to run that process. * we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly * we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept) * we have sent the following proposals back to revision - none - * we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept) We currently have to act on the following 5 proposals, down by 2. ## Waiting for committee decision #381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract "whither dependent Haskell". But what does this mean for this proposal? Iavor, can you pick this up again? #369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it? #302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he'll pick it up now again. ## Waiting for Shepherd action #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he'd reject it on the Github PR. Still waiting for the discussion to start on the mailing list. #390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704547033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=5wTbz6wc4abeqyC3TXDU2O8kftB9Rwz1dHnkXM%2FGErE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc1da190b85a4cf21e4b08d8d42ceb8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637492636704557030%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0MJhOYvjonZABu01LyVUN2zqOKC3xqf5qEidT8d%2B2os%3D&reserved=0

This is about #281 visible dependent quantification. Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way. If I were the shepherd I'd be asking the author "Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?" He might want to revise/discuss a bit. But if he says "please decide on it as-is" then I think you should make a recommendation: accept or reject. (I don't think the discussion has led to any specific revisions that we want to see.) I sense you would recommend reject. That's totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like "we are not ready to accept this now, so if you want a decision now, it'd be no; but feel free to ask the same question again in six months time". If you don't feel able to be the shepherd, that's fine too: tell Joachim and he'll finger someone else! But, by hook or by crook, I do think we should do something, not just sit on it. Tom's nudge is helpful. Simon From: Iavor Diatchki Sent: 05 March 2021 19:42 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Status I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like? I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281. My recommendation for the moment would be: * This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH. Please let me know what you think, as I am not sure what is the committee's stance on the proposal. -Iavor On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: There has been a broad further discussion. What we advertise is that, rather that leave a proposal "under committee review", we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That's different to reject... it means that there is an ongoing debate so it's not a good time for the committee to make a decision. Simon From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Iavor Diatchki Sent: 18 February 2021 16:47 To: Joachim Breitner mailto:mail@joachim-breitner.de> Cc: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Status On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal. I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this. Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up. -Iavor On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Dear Committee, another status update, because why not. A small reminder: These mails have two sections, one that's a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake). So here's the delta since last month. * GHC2021 defined! Yay! * Bylaws merged! Yay * Simon², Iavor, Richard and me had thus their terms expired. The Simons, as key members, wanted to continue and were voted back in. The others are now "expiring", until the next nomination round concludes. Alejandro is going to run that process. * we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly * we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept) * we have sent the following proposals back to revision - none - * we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept) We currently have to act on the following 5 proposals, down by 2. ## Waiting for committee decision #381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract "whither dependent Haskell". But what does this mean for this proposal? Iavor, can you pick this up again? #369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it? #302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he'll pick it up now again. ## Waiting for Shepherd action #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he'd reject it on the Github PR. Still waiting for the discussion to start on the mailing list. #390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561371493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hAny2jNi%2BPKhgMYqiwt4HyNDkvOSFSHKYfYKmrJ3qOk%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561381491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U6m9laT7pV9QEuzCyFXY2oZT4RFt2yFhDWuJE7YgIMM%3D&reserved=0

Hello, This is the author's response to my query: So, the situation seems to be as follows:

- if we want dependent types (as described on that Wiki page), I would like to resubmit

- if we do not want them, I will retract the proposal and close it

I need to know the committee’s stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise. -Iavor On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki wrote:

OK, I posted a note on the git-hub, asking @int-index what he wants to do. In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018...

another somewhat relevant discussion that followed was this:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018...

and here is a link to the proposal and the git-hub discussion: https://github.com/ghc-proposals/ghc-proposals/pull/281

-Iavor

On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones wrote:

...

This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way.

If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”

He might want to revise/discuss a bit. But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject. (I don’t think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject. That’s totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.

If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it. Tom’s nudge is helpful.

Simon

*From:* Iavor Diatchki *Sent:* 05 March 2021 19:42 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:

* This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor

On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones wrote:

There has been a broad further discussion.

What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Iavor Diatchki *Sent:* 18 February 2021 16:47 *To:* Joachim Breitner *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up.

-Iavor

On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner < mail@joachim-breitner.de> wrote:

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

* GHC2021 defined! Yay!

* Bylaws merged! Yay

* Simon², Iavor, Richard and me had thus their terms expired.

The Simons, as key members, wanted to continue and were voted back in.

The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process.

* we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly

* we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept)

* we have sent the following proposals back to revision - none -

* we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again.

## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561371493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hAny2jNi%2BPKhgMYqiwt4HyNDkvOSFSHKYfYKmrJ3qOk%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0f8040e69348485e5e2808d8e00ed1af%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505701561381491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U6m9laT7pV9QEuzCyFXY2oZT4RFt2yFhDWuJE7YgIMM%3D&reserved=0

I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together. Richard

On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee wrote:

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first. So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control. He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.

Simon

From: Iavor Diatchki Sent: 06 March 2021 16:51 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Status

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:

if we want dependent types (as described on that Wiki page), I would like to resubmit if we do not want them, I will retract the proposal and close it I need to know the committee’s stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

-Iavor

On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki mailto:iavor.diatchki@gmail.com> wrote: OK, I posted a note on the git-hub, asking @int-index what he wants to do. In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0

another somewhat relevant discussion that followed was this: https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0

and here is a link to the proposal and the git-hub discussion: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0

-Iavor

On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way.

If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”

He might want to revise/discuss a bit. But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject. (I don’t think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject. That’s totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.

If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it. Tom’s nudge is helpful.

Simon

From: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Sent: 05 March 2021 19:42 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Joachim Breitner mailto:mail@joachim-breitner.de>; ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:

* This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor

On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:

There has been a broad further discussion. What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.

Simon

From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Iavor Diatchki Sent: 18 February 2021 16:47 To: Joachim Breitner mailto:mail@joachim-breitner.de> Cc: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> Subject: Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up.

-Iavor

On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

* GHC2021 defined! Yay!

* Bylaws merged! Yay

* Simon², Iavor, Richard and me had thus their terms expired.

The Simons, as key members, wanted to continue and were voted back in.

The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process.

* we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly

* we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept)

* we have sent the following proposals back to revision - none -

* we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again.

## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon's suggestion sounds like the proper thing to do to me too. The connection between #281 and dependent types is a little superficial, but it #281 mixes the type syntax and the term syntax a bit more (in fact, most of the details in the proposal are about that). The ability to mix types and terms some way or another is central to having more dependent typing. So there is, at the very least, a need for synchronization between the various corresponding proposals. Though, in fact, this visible forall thing is part of the dependent type package that Richard has been working towards. It does fit somewhat naturally in the big picture. On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki wrote:

I will wait a few more days to see if anyone else expresses an opinion, otherwise I'll do as Simon suggests.

Could someone clarify what does #281 have to do with dependent types? The example that was brought up, and I think is pretty reasonable, is `sizeOf` from the `Storbale` class: I might want to write `sizeOf @Bool`. Is the plan to require that dependent types are enabled to write stuff like that?

-Iavor

On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg wrote:

...

I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.

Richard

On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee wrote:

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first. So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control. He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.

Simon

*From:* Iavor Diatchki *Sent:* 06 March 2021 16:51 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:

- if we want dependent types (as described on that Wiki page), I would like to resubmit

- if we do not want them, I will retract the proposal and close it

I need to know the committee’s stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

-Iavor

On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki wrote:

OK, I posted a note on the git-hub, asking @int-index what he wants to do. In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0

another somewhat relevant discussion that followed was this:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0

and here is a link to the proposal and the git-hub discussion: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0

-Iavor

On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones wrote:

This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way.

If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”

He might want to revise/discuss a bit. But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject. (I don’t think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject. That’s totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.

If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it. Tom’s nudge is helpful.

Simon

*From:* Iavor Diatchki *Sent:* 05 March 2021 19:42 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:

* This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor

On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones wrote:

There has been a broad further discussion. What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Iavor Diatchki *Sent:* 18 February 2021 16:47 *To:* Joachim Breitner *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up.

-Iavor

On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner < mail@joachim-breitner.de> wrote:

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

* GHC2021 defined! Yay!

* Bylaws merged! Yay

* Simon², Iavor, Richard and me had thus their terms expired.

The Simons, as key members, wanted to continue and were voted back in.

The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process.

* we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly

* we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept)

* we have sent the following proposals back to revision - none -

* we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again.

## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I still don't see what `sizeOf Bool` has to do with dependent types---there does not appear to be a semantic difference between `sizeOf @Bool` and `sizeOf Bool`, rather it is just a notational difference. I am really missing the vision of where folks are picturing us ending up with all these changes. Is the thinking that anyone who wants to use the FFI should have to enable dependent types? -Iavor On Tue, Mar 9, 2021 at 11:33 AM Richard Eisenberg wrote:

I agree with Arnaud. The connection to dependent types is pretty tangential, really: it's all about whether we have `sizeOf @Bool` or `sizeOf Bool`. If we had no intention of dependent types, I'd probably favor the former. But forward-compatibility with the design sketch for dependent types ( https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell) suggests using the latter. The problem is that the latter choice is more challenging to support, and indeed drives much of the complexity in the proposal.

So, we are a bit stuck: do we favor the design that's easier to specify and implement today? or do we favor the design that will mesh better tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will inform this decision.

Richard

On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud wrote:

Simon's suggestion sounds like the proper thing to do to me too.

The connection between #281 and dependent types is a little superficial, but it #281 mixes the type syntax and the term syntax a bit more (in fact, most of the details in the proposal are about that). The ability to mix types and terms some way or another is central to having more dependent typing. So there is, at the very least, a need for synchronization between the various corresponding proposals. Though, in fact, this visible forall thing is part of the dependent type package that Richard has been working towards. It does fit somewhat naturally in the big picture.

On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki wrote:

...

I will wait a few more days to see if anyone else expresses an opinion, otherwise I'll do as Simon suggests.

Could someone clarify what does #281 have to do with dependent types? The example that was brought up, and I think is pretty reasonable, is `sizeOf` from the `Storbale` class: I might want to write `sizeOf @Bool`. Is the plan to require that dependent types are enabled to write stuff like that?

-Iavor

On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg wrote:

...

I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.

Richard

On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee wrote:

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first. So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control. He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.

Simon

*From:* Iavor Diatchki *Sent:* 06 March 2021 16:51 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:

- if we want dependent types (as described on that Wiki page), I would like to resubmit

- if we do not want them, I will retract the proposal and close it

I need to know the committee’s stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

-Iavor

On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki wrote:

OK, I posted a note on the git-hub, asking @int-index what he wants to do. In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0

another somewhat relevant discussion that followed was this:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0

and here is a link to the proposal and the git-hub discussion: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0

-Iavor

On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones wrote:

This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way.

If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”

He might want to revise/discuss a bit. But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject. (I don’t think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject. That’s totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.

If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it. Tom’s nudge is helpful.

Simon

*From:* Iavor Diatchki *Sent:* 05 March 2021 19:42 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:

* This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor

On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones < simonpj@microsoft.com> wrote:

There has been a broad further discussion. What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Iavor Diatchki *Sent:* 18 February 2021 16:47 *To:* Joachim Breitner *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up.

-Iavor

On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner < mail@joachim-breitner.de> wrote:

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

* GHC2021 defined! Yay!

* Bylaws merged! Yay

* Simon², Iavor, Richard and me had thus their terms expired.

The Simons, as key members, wanted to continue and were voted back in.

The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process.

* we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly

* we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept)

* we have sent the following proposals back to revision - none -

* we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again.

## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Tue, Mar 9, 2021 at 12:22 PM Richard Eisenberg wrote:

On Mar 9, 2021, at 3:12 PM, Iavor Diatchki wrote:

I still don't see what `sizeOf Bool` has to do with dependent types---there does not appear to be a semantic difference between `sizeOf @Bool` and `sizeOf Bool`, rather it is just a notational difference.

Yes -- it's exactly the notational difference that's at issue. It's all a question of whether we want to require users to write @ before a required dependent (or type-level) argument. That really is it, but a good choice on this narrow (for me) hinges on whether or not we are working toward a future with dependent types.

For what it's worth I find `sizeOf @Bool` considerably more readable than `sizeOf Bool`.

I am really missing the vision of where folks are picturing us ending up with all these changes. Is the thinking that anyone who wants to use the FFI should have to enable dependent types?

No. It's possible they would need no extensions at all. If there is no data constructor in scope named Bool, then sizeOf Bool might be accepted without any extensions on, I think. We often require an extension only at the definition site, not at usage sites.

Does this help?

Well, it sounds like you are saying that to use FFI one would have to buy into DH design. My concern is not about what pragmas the users have to write---after all we could make them write no pragams whatsoever. It is about what users would have to understand. For example, why does it matter that there is no data constructor `Bool` in scope? I am passing a type to `sizeOf`, why would GHC all of a sudden get confused between the type and the value?

On Tue, Mar 9, 2021 at 11:33 AM Richard Eisenberg wrote:

...

I agree with Arnaud. The connection to dependent types is pretty tangential, really: it's all about whether we have `sizeOf @Bool` or `sizeOf Bool`. If we had no intention of dependent types, I'd probably favor the former. But forward-compatibility with the design sketch for dependent types ( https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell) suggests using the latter. The problem is that the latter choice is more challenging to support, and indeed drives much of the complexity in the proposal.

So, we are a bit stuck: do we favor the design that's easier to specify and implement today? or do we favor the design that will mesh better tomorrow (assuming tomorrow has dependent types)? Our answer to #378 will inform this decision.

Richard

On Mar 9, 2021, at 3:02 AM, Spiwack, Arnaud wrote:

Simon's suggestion sounds like the proper thing to do to me too.

The connection between #281 and dependent types is a little superficial, but it #281 mixes the type syntax and the term syntax a bit more (in fact, most of the details in the proposal are about that). The ability to mix types and terms some way or another is central to having more dependent typing. So there is, at the very least, a need for synchronization between the various corresponding proposals. Though, in fact, this visible forall thing is part of the dependent type package that Richard has been working towards. It does fit somewhat naturally in the big picture.

On Tue, Mar 9, 2021 at 6:58 AM Iavor Diatchki wrote:

...

I will wait a few more days to see if anyone else expresses an opinion, otherwise I'll do as Simon suggests.

Could someone clarify what does #281 have to do with dependent types? The example that was brought up, and I think is pretty reasonable, is `sizeOf` from the `Storbale` class: I might want to write `sizeOf @Bool`. Is the plan to require that dependent types are enabled to write stuff like that?

-Iavor

On Mon, Mar 8, 2021 at 8:35 PM Richard Eisenberg wrote:

...

I have now submitted #378 for a committee decision (though I will forgive Joachim if he missed the notification among the 200 comments on that thread). So perhaps we can tackle all of this together.

Richard

On Mar 8, 2021, at 8:54 AM, Simon Peyton Jones via ghc-steering-committee wrote:

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

I would suggest that rather than “reject” (which sounds like “we don’t want this, don’t resubmit it”), we push it back saying that we agree that it’d be better to settle #378 first. So we we’ll mark it as “needs revision” not because we have anything specific to suggest, but so that it’s back in the author’s control. He should feel free to re-submit (perhaps revised in some way, as he sees fit) once #378 is resolved.

Simon

*From:* Iavor Diatchki *Sent:* 06 March 2021 16:51 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

Hello,

This is the author's response to my query:

So, the situation seems to be as follows:

- if we want dependent types (as described on that Wiki page), I would like to resubmit

- if we do not want them, I will retract the proposal and close it

I need to know the committee’s stance on dependent types to proceed here.

I don't think this proposal is the right place to discuss dependent types, so I propose that we reject the proposal. To ensure progress, I'll do so within a week, so please discuss before then, if you think otherwise.

-Iavor

On Fri, Mar 5, 2021 at 5:02 PM Iavor Diatchki wrote:

OK, I posted a note on the git-hub, asking @int-index what he wants to do. In case anyone needs a refresher, this is the discussion we had when I submitted this to the committee back in November:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001859.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581487239%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2inDHN90f7OQ9XIcd76l50Lwwp6axEUZVdea%2BoRFZzg%3D&reserved=0

another somewhat relevant discussion that followed was this:

https://mail.haskell.org/pipermail/ghc-steering-committee/2020-November/0018... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2020-November%2F001865.html&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k4jiWTo11nNFH6zHyw7oYMFfyl0kxkQEsXKSueeC2Mk%3D&reserved=0

and here is a link to the proposal and the git-hub discussion: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581497234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7tkk61XrEd9utRxcQjA3Eh3Wi3cDXuJdMae%2BBcx3gM%3D&reserved=0

-Iavor

On Fri, Mar 5, 2021 at 3:13 PM Simon Peyton Jones < simonpj@microsoft.com> wrote:

This is about #281 visible dependent quantification.

Our role is to accept, reject, or push back to the author for revision. We should do so in a timely way.

If I were the shepherd I’d be asking the author “Do you want to revise the proposal at all in the light of all the discussion, or do you want the committee to decide yay/nay based on the proposal as it is now?”

He might want to revise/discuss a bit. But if he says “please decide on it as-is” then I think you should make a recommendation: accept or reject. (I don’t think the discussion has led to any specific revisions that we want to see.)

I sense you would recommend reject. That’s totally fine. Then the rest of us have to make up our minds. We might end up with a more nuanced position like “we are not ready to accept this now, so if you want a decision now, it’d be no; but feel free to ask the same question again in six months time”.

If you don’t feel able to be the shepherd, that’s fine too: tell Joachim and he’ll finger someone else!

But, by hook or by crook, I do think we should do something, not just sit on it. Tom’s nudge is helpful.

Simon

*From:* Iavor Diatchki *Sent:* 05 March 2021 19:42 *To:* Simon Peyton Jones *Cc:* Joachim Breitner ; ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

I am being nudged to do something with this proposal, but I am not sure what... Is the rest of the committee OK with moving it back "revisions required", and if so what revisions would we like?

I would be quite happy if someone else wanted to shephard this. As I mentioned before, I don't have much interest in DH, so I have not followed the really long discussion related to that, and if and how it might relate to #281.

My recommendation for the moment would be:

* This seems like a useful feature independent of DH, so it would be nice to come up with a concise notation to use the feature on its own, without worrying about DH.

Please let me know what you think, as I am not sure what is the committee's stance on the proposal.

-Iavor

On Thu, Feb 18, 2021 at 1:54 PM Simon Peyton Jones < simonpj@microsoft.com> wrote:

There has been a broad further discussion. What we advertise is that, rather that leave a proposal “under committee review”, we will push it back to the author with an invitation to resubmit when the discussion has died down and they feel ready to submit a proposal, revised in the light of the discussion. That’s different to reject… it means that there is an ongoing debate so it’s not a good time for the committee to make a decision.

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Iavor Diatchki *Sent:* 18 February 2021 16:47 *To:* Joachim Breitner *Cc:* ghc-steering-committee *Subject:* Re: [ghc-steering-committee] Status

On #381 I think the idea of visible quantification makes sense every now and then, but I don't like the concrete details of the proposal: the magic lifting of terms to types seems quite complicated, and using `type` as an explicit herald doesn't look nice. So I don't think it's the right design, and therefore I suggest we reject the proposal.

I am sure that others would disagree as apparently this is an essential part of dependent Haskell. I have not followed the large discussion that Richard created, as I am not particularly interested in the design being proposed, so perhaps someone else should champion this.

Aslo, I am not sure if I am actually on the committee, as I thought my term had expired? That might be more reason for someone else to pick it up.

-Iavor

On Thu, Feb 18, 2021 at 2:32 AM Joachim Breitner < mail@joachim-breitner.de> wrote:

Dear Committee,

another status update, because why not.

A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake).

So here’s the delta since last month.

* GHC2021 defined! Yay!

* Bylaws merged! Yay

* Simon², Iavor, Richard and me had thus their terms expired.

The Simons, as key members, wanted to continue and were voted back in.

The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process.

* we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly

* we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept)

* we have sent the following proposals back to revision - none -

* we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept)

We currently have to act on the following 5 proposals, down by 2.

## Waiting for committee decision

#381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again?

#369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it?

#302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again.

## Waiting for Shepherd action

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list.

#390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581507230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gsdKkpp3AhJz2ins9uuctT%2FGf6rr2bScSHFWyX3jFhM%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C0b9f9dd78f934d620c5e08d8e0c0012f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637506462581517226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BY04FgtL9RHpjI6frr%2BOYfxwPkW5yjN2DeRyv2JaKN4%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Tue, Mar 9, 2021 at 8:11 PM Richard Eisenberg wrote:

On Mar 9, 2021, at 3:34 PM, Iavor Diatchki wrote:

Well, it sounds like you are saying that to use FFI one would have to buy into DH design. My concern is not about what pragmas the users have to write---after all we could make them write no pragams whatsoever. It is about what users would have to understand. For example, why does it matter that there is no data constructor `Bool` in scope? I am passing a type to `sizeOf`, why would GHC all of a sudden get confused between the type and the value?

Just as much as users of arithmetic have to buy into a design using type-classes. That is, we're aiming to design a cohesive language, and that means that someone trying to understand the design of the language (i.e. our FFI user) will have to consider it holistically.

I don't see how type-classes are related to the current point. Yes, we want to consider a cohesive language design, but this doesn't mean that everything has to depend on everything. The nice benefit of the extension system is that it allows us to experiment with language changes modularly. As I see it, here we have a choice between: A. a modular opt-int design that is close to what is already used by a lot of a projects (i.e., something like `sizeOf @Bool`), and B. an alternative design (i..e, `sizeOf Bool`) that depends on an unrelated feature (dependent types), that we have zero experience with, and require major changes to how something as basic as name resolution works. It sounds like #378 is asking us to always make choice B. I think a better plan is to prefer option A, as we have been for a long time now. I don't think that precludes the work on dependent types in any way (ergonomic or not, whatever that means). Once that work is done, it might subsume some existing extensions, and folks would have a choice to write things one way or another depending on their needs. I expect in the long run, one of the designs might become the common way to do stuff, and eventually we might depreciate some of the extensions that are not used any more. To me, this seems to be the right way to grow a living language like Haskell. As for confusion between types and values: this is the heart of the matter.

I agree that, taking #281 alone, it would make more sense to say sizeOf @Bool. But in the context of a design that might support dependent types, it makes more sense to say sizeOf Bool, and have name lookup try both namespaces (the data constructor namespace first, followed by the type namespace). This is why I wrote #378, so that we could decide which design is better for #281.

I don't see how `sizeOf Bool` makes more sense than `sizeOf @Bool` in a language with dependent types, this seems purely a matter of taste. As I mentioned before, I find `sizeOf @Bool` more readable than `sizeOf Bool` exactly because I don't need to keep in my head yet another thing (i.e., which `Bool` are we talking about here). By the way, in case the `Bool` example seems absurd, using `newtype`s is quite common when doing FFI bindings, and the normal pattern there is to use the same name for the value and type constructor, so this is something that we should not gloss over lightly. -Iavor