<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 13, 2022 at 2:51 AM Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
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.<br>
<br>
I recommend acceptance of the proposal, but there is one question that I would like the broader committee to engage on. <br>
<br>
Simon and Richard have proposed introducing another arrow type as part of this proposal.<br>
<br>
type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep).<br>
              CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint<br>
<br>
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.<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818</a><br>
<br>
Thanks!<br>
Eric <br>
<br>
On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:<br>
> Dear Committee,<br>
><br>
> The Type vs Constraint proposal<br>
> has been submitted by Richard Eisenberg and Simon Peyton Jones<br>
><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/518" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/518</a><br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst</a><br>
><br>
> I suggest that Eric shepherds this proposal.<br>
><br>
> Please guide us to a conclusion as outlined in <br>
> <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
><br>
> Thanks,<br>
> Joachim<br>
><br>
><br>
><br>
><br>
><br>
> -- <br>
> Joachim Breitner<br>
>   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
>   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>