<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">My silence on this proposal is because I want to accept, but I agree with Iavor that it's become too baroque. My #378 is, in part, an attempt to clarify our stance on these sorts of features so that we can take a stab at simplifying #281 by making it less expressive.<div class=""><br class=""></div><div class="">So, I guess my vote is to delay decision on this proposal until we have one for #378 (or #270, which can also help shed light on this one).</div><div class=""><br class=""></div><div class="">Responding directly to Alejandro's concerns here: I actually don't really understand. I think (1) is decided by <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0081-forall-arrow.rst" class="">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0081-forall-arrow.rst</a>; we use this syntax in standalone kind signatures in GHC 8.10. We *could* change this if there were a compelling reason, but this proposal is just continuing an existing feature. By (2), I think you're referring to all the complications in the proposals at how to deal with names and syntax in arguments -- I wouldn't myself describe this as conflating the two namespaces, but rather as defining a subtle set of rules for interpreting ambiguous names. It's the subtlety of these rules that makes me uncomfortable. For (3), I don't really think there's much there -- and what there is seems to require (2) (and vice versa). Do you have an example of a type-inference interaction you're worried about here?</div><div class=""><br class=""></div><div class="">Richard<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" class="">trupill@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div dir="ltr" style="font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)" class="">Hi all,</div><div dir="ltr" style="font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)" class="">For me, there are two main concerns here:</div><div dir="ltr" style="font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)" class=""><ol style="margin:0px;border-color:rgb(49,49,49)" class=""><li style="font-size:1rem;border-color:rgb(49,49,49)" class="">This could be split on different proposals: (1) using the “forall a ->” syntax, (2) conflating the type and term syntax and namespaces, (3) introducing checking and inference for it;</li><li style="font-size:1rem;border-color:rgb(49,49,49)" class="">I find the claim that you can just take the Quick Look Impredicativity paper, make a couple of adjustments, and get correct checking and inference. This kind of big change is the one for which I would actually expect a peer-reviewed paper.</li></ol><div style="border-color:rgb(49,49,49)" class=""><br class=""></div><div style="font-size:1rem;border-color:rgb(49,49,49)" class="">Regards,</div><div style="font-size:1rem;border-color:rgb(49,49,49)" class="">Alejandro</div></div></div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> escribió:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Dear Committee,<br class="">
<br class="">
Iavor suggested to reject this proposal, but we have not heard a lot<br class="">
here yet. Especially before rejecting proposals, we probably owe a<br class="">
careful analysis, possibly with suggestions of ways forward (splitting<br class="">
the proposal into smaller pieces maybe? Iavor says there are many<br class="">
changes there).<br class="">
<br class="">
If we have continued silence, we’d reject.<br class="">
<br class="">
Cheers,<br class="">
Joachim<br class="">
<br class="">
<br class="">
Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki:<br class="">
> Hello,<br class="">
> <br class="">
> Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text:<br class="">
> <br class="">
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/281</a><br class="">
> <a href="https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst" rel="noreferrer" target="_blank" class="">https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst</a><br class="">
> <br class="">
> While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it.<br class="">
> <br class="">
> I'd be curious about what others think.<br class="">
> <br class="">
> -Iavor<br class="">
> <br class="">
> <br class="">
> _______________________________________________<br class="">
> ghc-steering-committee mailing list<br class="">
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></div></body></html>