<div dir="ltr">I'd just like to echo that I really like Austin's suggestion as well, as it very nicely unifies the two usecases, while simultaneously <i>not </i>dramatically increasing scope.<div><br></div><div>-Edward</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg <span dir="ltr"><<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">First of all: Yay! I've been wanting this for some time. I'm sorry I missed your presentation at PADL about this.<br>

<br>
I, personally, rather like the design. There may be fine points of discussion as it all becomes reality, but I think this is a great approach -- much like what I've envisioned whenever thinking about the problem.<br>

<br>
I would allow _ only as a constraint extension and _a in a constraint only when it also appears in the mono-type. I think, contrary to the wiki page, that the scope of named wildcards should mirror the behavior of normal type variables. Yes, it's weird that scoped type variables don't work by default, but I think it's weirder still if some scoped type-variable-like things work and others don't. I don't imagine that this fine control is hard to implement.<br>

<br>
I think Austin's suggestion below is equally great. Just has 7.8 will now report informative errors when _ is used in an expression position, the implementation for partial type signatures can easily spit out informative errors when _ is used in a type. This would not be an extension, because it does not change the set of programs that compile nor the behavior of compiled programs. However, if a user specifies -XPartialTypeSignatures, then the errors are not reported -- the inferred type is simply used.<br>

<br>
Thanks so much for doing this!<br>
<span class="HOEnZb"><font color="#888888"><br>
Richard<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mar 13, 2014, at 4:22 PM, Austin Seipp wrote:<br>
<br>
> On Thu, Mar 13, 2014 at 7:18 AM, Thomas Winant<br>
> <<a href="mailto:thomas.winant@cs.kuleuven.be">thomas.winant@cs.kuleuven.be</a>> wrote:<br>
>> However, we have the impression that no Hole should remain unfilled,<br>
>> whereas using a partial type signature doesn't necessarily mean the<br>
>> program is incomplete. A partial type signature can still be a<br>
>> (stylistic) choice.<br>
><br>
> Yes, this is the main hold up I was thinking of. Thinking about it a<br>
> little more, one way to resolve it perhaps would be to do something<br>
> similar to we did to typed holes at the term level: make 'holes' at<br>
> the type level an error by default, which when encountered spit out<br>
> the error containing the type each hole was instantiated to, and what<br>
> the partial type signatures would be inferred as. Then, if you enable<br>
> -XPartialTypeSignatures, these would cease to be errors providing the<br>
> compiler can infer the types sensibly (and it wouldn't alert you in<br>
> that case).<br>
><br>
> That might be a half baked idea (I just sat here for about 5 minutes),<br>
> but either way I say again I do support -XPartialTypeSignatures<br>
> anyway, and it sounds like a step in the right direction. :)<br>
><br>
> --<br>
> Regards,<br>
><br>
> Austin Seipp, Haskell Consultant<br>
> Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>