<div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>my concern is mainly with introducing multiple language constructs that do almost the same thing and neither is better than the other as I think this complicates the language unnecessarily.</div><div><br></div><div>Vladislav, I am not sure of the details of your example, but isn't it the case that you could write it with scoped type variables if you wrote the type down?   I agree that this can be a pain,</div><div>and as far as I see, this is the main use case for this feature---it provides an easier way to call higher-rank functions, when you need to refer to the type parameter in the polymorphic argument.</div><div><br></div><div>-Iavor </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 22, 2019 at 2:48 AM Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com">vlad.z.4096@gmail.com</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">Dear GHC steering committee,<br>
<br>
> In the end, this proposal does not bring in much over ScopedTypeVariables<br>
<br>
Please note that comparing this feature to ScopedTypeVariables does<br>
not capture the full picture. There are two examples of code in the<br>
proposal, which I provided, that cannot be expressed using<br>
ScopedTypeVariables without a dummy Proxy argument.<br>
<br>
> With finite effort cycles, we may have more important fish to fry.<br>
<br>
I was planning to implement this proposal if it would be accepted.<br>
<br>
All the best,<br>
- Vladislav<br>
</blockquote></div></div>