[ghc-steering-committee] Please review #518: Type vs Constraint proposal, Shepherd: Eric

[Spiwack, Arnaud]

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 at 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 <eric at seidel.io> 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_r917416818
>>
>> 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/proposals/0000-type-vs-constraint.rst
>> >
>> > 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 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
>>
> _______________________________________________
> 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/20220912/d71fde8a/attachment.html>