Hi Simon,<div><br></div><div>Thanks for all your work in getting TypeHoles into HEAD. We really appreciate it.</div><div><br></div><div>I was playing around with HEAD today and wanted to share a few observations.</div><div>

<br>
</div><div>(1) One of the ideas we had was that a hole `_&#39; would be like `undefined&#39; but with information about the type and bindings. But in the current version, there doesn&#39;t appear to be that connection. This mainly applies to ambiguous type variables.</div>



<div><br></div><div>Consider:</div><div>&gt; f = show _</div><div>The hole has type a0.</div><div><br></div><div>But with</div><div>&gt; f = show undefined</div><div>there is a type error because a0 is ambiguous.</div><div>


<br></div><div>We were thinking that it would be better to report the ambiguous type variable first, rather than the hole. In that case, tou can use -fdefer-type-errors to defer the error. Currently, you don&#39;t have that option. I can see the argument either way, however, and I&#39;m not sure which is better.</div>


<div><br></div><div>(2) There is a strange case where an error is not reported for a missing type class instance, even though there is no (apparent) relation between the missing instance and the hole. (This also relates to the connection to `undefined&#39;, but less directly.)</div>


<div><br></div><div>We have the following declaration:</div><div><div>&gt; data T = T Int {- no Show instance -}</div><div><br></div><div>With a hole in the field</div>
<div>
&gt; g = show (T _)</div></div><div>we get a message that the hole has type Int.</div><div><br></div><div>With</div><div>&gt; g = show (T undefined)</div><div>we get an error for the missing instance of `Show T&#39;.</div>


<div><br></div><div>(3) In GHCi, I see that the type of the hole now defaults. This is not necessarily bad, though it&#39;s maybe not as useful as it could be.</div><div><br></div><div>ghci&gt; :t show _</div><div>reports that the hole has type ().</div>



<div><br></div><div>(4) In GHCi, sometimes a hole throws an exception, and sometimes it does not.</div><div><br></div><div>ghci&gt; show _</div><div>throws an exception with the hole warning message</div><div><br></div><div>


ghci&gt; show (T _)</div><div>and</div><div>ghci&gt; _ + 42</div>
<div>cause GHCi to panic.</div><div><br></div><div>(5) There are some places where unnecessary parentheses are used when pretty-printing the code:</div><div><br></div><div><div>ghci&gt; :t _ _</div><div><br></div><div>&lt;interactive&gt;:1:1: Warning:</div>


<div>    Found hole `_&#39; with type t0 -&gt; t</div><div>    Where: `t0&#39; is a free type variable</div><div>           `t&#39; is a rigid type variable bound by</div><div>               the inferred type of it :: t at Top level</div>


<div>    In the expression: _</div><div>    In the expression: _ (_)</div><div><br></div><div>&lt;interactive&gt;:1:3: Warning:</div><div>    Found hole `_&#39; with type t0</div><div>    Where: `t0&#39; is a free type variable</div>


<div>    In the first argument of `_&#39;, namely `_&#39;</div><div>    In the expression: _ (_)</div><div>_ _ :: t</div></div><div><br></div><div>The argument `_&#39; does not need to be printed as `(_)&#39;.</div><div>

<br></div><div>There is also the small matter, in this example, of distinguishing which `_&#39; is which. The description works, but you have to think about it. I don&#39;t have an immediate and simple solution to this. Perhaps the addition of unique labels (e.g. _$1 _$2). But this is not a major problem. It can even wait until some future development/expansion on TypeHoles.</div>


<div><br></div><div>Regards,</div><div>Sean</div>