Please review #518: Type vs Constraint proposal, Shepherd: Eric

Joachim Breitner

6 Jul 2022 6 Jul '22

8:10 a.m.

Dear Committee, The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones https://github.com/ghc-proposals/ghc-proposals/pull/518 https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/p... I suggest that Eric shepherds this proposal. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Show replies by date

Hi all, Richard and Simon PJ have proposed tightening up the distinction between Type and Constraint in the type system. This proposal is primarily motivated by eliminating a long-standing class of compiler bugs, but it introduces a number of new (user-facing) types at the core of GHC's type system. And it does bring with it some additional capabilities like unboxed and unlifted implicit parameters, and a greater ability to abstract over arrows. I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on. Simon and Richard have proposed introducing another arrow type as part of this proposal. type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint I am a bit wary of introducing this arrow as a stable API at this point. It does not seem strictly necessary to make this part of the public API to implement this proposal, but doing so would commit us to a particular point in the design space. I've started a thread to discuss this on GitHub, please take a look and chime in if you have thoughts. https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r91741681... Thanks! Eric On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:

...

Dear Committee,

The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones

https://github.com/ghc-proposals/ghc-proposals/pull/518 https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/p...

I suggest that Eric shepherds this proposal.

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

Thanks, Joachim

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

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

Spiwack, Arnaud

13 Jul 13 Jul

10:52 a.m.

As I've voiced in the thread, I'm not particularly fond of this proposal's design. That being said, the issues it means to address are serious, and they are pressing. Simon and Richard think it's the best path forward for them, and therefore I vote acceptance. On Wed, Jul 13, 2022 at 2:51 AM Eric Seidel wrote:

...

Hi all,

Richard and Simon PJ have proposed tightening up the distinction between Type and Constraint in the type system. This proposal is primarily motivated by eliminating a long-standing class of compiler bugs, but it introduces a number of new (user-facing) types at the core of GHC's type system. And it does bring with it some additional capabilities like unboxed and unlifted implicit parameters, and a greater ability to abstract over arrows.

I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on.

Simon and Richard have proposed introducing another arrow type as part of this proposal.

type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint

I am a bit wary of introducing this arrow as a stable API at this point. It does not seem strictly necessary to make this part of the public API to implement this proposal, but doing so would commit us to a particular point in the design space. I've started a thread to discuss this on GitHub, please take a look and chime in if you have thoughts.

https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r91741681...

Thanks! Eric

On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:

...
Dear Committee,

The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones

https://github.com/ghc-proposals/ghc-proposals/pull/518

https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/p...

...
I suggest that Eric shepherds this proposal.

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

Thanks, Joachim

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

_______________________________________________ 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

Simon Peyton Jones

11 Sep 11 Sep

5:30 p.m.

Eric Would it be possible to conclude this discussion now? And (I earnestly hope) accept the proposal? I don't think it's controversial, and it barely needs a proposal anyway (since it's mainly about GHC internals). I thought I'd start work on implementing it, in case that threw up any issues. I got drawn in, and have not invested about two person weeks in the MR. So I'm keen to get this done. Thanks! Simon On Wed, 13 Jul 2022 at 01:51, Eric Seidel wrote:

...

Hi all,

Richard and Simon PJ have proposed tightening up the distinction between Type and Constraint in the type system. This proposal is primarily motivated by eliminating a long-standing class of compiler bugs, but it introduces a number of new (user-facing) types at the core of GHC's type system. And it does bring with it some additional capabilities like unboxed and unlifted implicit parameters, and a greater ability to abstract over arrows.

I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on.

Simon and Richard have proposed introducing another arrow type as part of this proposal.

type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint

I am a bit wary of introducing this arrow as a stable API at this point. It does not seem strictly necessary to make this part of the public API to implement this proposal, but doing so would commit us to a particular point in the design space. I've started a thread to discuss this on GitHub, please take a look and chime in if you have thoughts.

https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r91741681...

Thanks! Eric

On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:

...
Dear Committee,

The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones

https://github.com/ghc-proposals/ghc-proposals/pull/518

https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/p...

...
I suggest that Eric shepherds this proposal.

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

Thanks, Joachim

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

_______________________________________________ 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

Spiwack, Arnaud

12 Sep 12 Sep

3:01 a.m.

I've already spoken in favour of acceptance. But I should say that the objections that I had do not hold in the current iteration of the proposal. So I'm wholeheartedly in favour of acceptance. (In fact, this proposal is barely a user-facing change, I don't think that there is any obstacle to accepting the proposal within the week). On Sun, Sep 11, 2022 at 11:30 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Eric

Would it be possible to conclude this discussion now? And (I earnestly hope) accept the proposal? I don't think it's controversial, and it barely needs a proposal anyway (since it's mainly about GHC internals).

I thought I'd start work on implementing it, in case that threw up any issues. I got drawn in, and have not invested about two person weeks in the MR. So I'm keen to get this done. Thanks!

Simon

On Wed, 13 Jul 2022 at 01:51, Eric Seidel wrote:

...
Hi all,

Richard and Simon PJ have proposed tightening up the distinction between Type and Constraint in the type system. This proposal is primarily motivated by eliminating a long-standing class of compiler bugs, but it introduces a number of new (user-facing) types at the core of GHC's type system. And it does bring with it some additional capabilities like unboxed and unlifted implicit parameters, and a greater ability to abstract over arrows.

I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on.

Simon and Richard have proposed introducing another arrow type as part of this proposal.

type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint

I am a bit wary of introducing this arrow as a stable API at this point. It does not seem strictly necessary to make this part of the public API to implement this proposal, but doing so would commit us to a particular point in the design space. I've started a thread to discuss this on GitHub, please take a look and chime in if you have thoughts.

https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r91741681...

Thanks! Eric

On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:

...
Dear Committee,

The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones

https://github.com/ghc-proposals/ghc-proposals/pull/518

https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/p...

...
I suggest that Eric shepherds this proposal.

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

Thanks, Joachim

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

_______________________________________________ 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

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

Eric Seidel

9:05 a.m.

On Sun, Sep 11, 2022, at 17:30, Simon Peyton Jones wrote:

...

Would it be possible to conclude this discussion now? And (I earnestly hope) accept the proposal? I don't think it's controversial, and it barely needs a proposal anyway (since it's mainly about GHC internals).

Yes, sorry. I believe we have consensus on the proposed changes themselves, but were stalled on the question of how to cleanly define the public API boundaries of GHC-the-library. This proposal clearly specifies which types are public and which are internal, and we have two related proposals exploring the question of how to specify public API boundaries: * https://github.com/ghc-proposals/ghc-proposals/pull/524 * https://github.com/ghc-proposals/ghc-proposals/pull/528 My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation. Richard, you were the main voice expressing concern about public API boundaries. Can we just merge this proposal and continue the public API discussion in #524 and #528?

Joachim Breitner

11:32 a.m.

Hi, Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:

...

My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Eric Seidel

17 Sep 17 Sep

11:33 a.m.

Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal. On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:

...

Hi,

Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:

...
My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way.

Cheers, Joachim

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

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

Richard Eisenberg

27 Sep 27 Sep

4:42 p.m.

Yes, I'm fine here -- would still love to have this worked out, but I don't want to hold things up further. Richard

...

On Sep 17, 2022, at 11:33 AM, Eric Seidel wrote:

Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.

On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:

...
Hi,

Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:

...
My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way.

Cheers, Joachim

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

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

Eric Seidel

9:10 p.m.

Thanks Richard! Joachim, I think we're good to merge now! On Tue, Sep 27, 2022, at 16:42, Richard Eisenberg wrote:

...

Yes, I'm fine here -- would still love to have this worked out, but I don't want to hold things up further.

Richard

...
On Sep 17, 2022, at 11:33 AM, Eric Seidel wrote:

Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.

On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:

...
Hi,

Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:

...
My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way.

Cheers, Joachim

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

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

Joachim Breitner

2 Oct 2 Oct

7:59 a.m.

Done! Am Dienstag, dem 27.09.2022 um 21:10 -0400 schrieb Eric Seidel:

...

Thanks Richard!

Joachim, I think we're good to merge now!

On Tue, Sep 27, 2022, at 16:42, Richard Eisenberg wrote:

...
Yes, I'm fine here -- would still love to have this worked out, but I don't want to hold things up further.

Richard

...
On Sep 17, 2022, at 11:33 AM, Eric Seidel wrote:

Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.

On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:

...
Hi,

Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:

...
My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way.

Cheers, Joachim

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

_______________________________________________ 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

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

961

Age (days ago)

1049

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Eric Seidel
Joachim Breitner
Richard Eisenberg
Simon Peyton Jones
Spiwack, Arnaud

Please review #518: Type vs Constraint proposal, Shepherd: Eric

tags

participants (5)