<div dir="ltr">(a bit late to the discussion, so please ignore if this is completely off-base)<br><div><div><br>On Mon, Dec 2, 2013 at 9:17 PM, AntC <span dir="ltr"><<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">> Richard Eisenberg <eir <at> <a href="http://cis.upenn.edu" target="_blank">cis.upenn.edu</a>> writes:<br>

><br>
> - The notion of "competing instances" for type families sounds somewhat<br>
</div>> like delayed overlap checks for class instances. ...<br>
<br>
No. No delay. The point is to validate eagerly at the point of declaring<br>
the instance (and whether or not it's in some other module).<br>
The guards guarantee that no instances overlap.<br>
Importing an overlapping instance is trapped immediately;<br>
no risk of incoherence.<br></blockquote><div><br></div><div>How can this possibly work with open type families?  What happens in this case?<br><br>> module A where<br>
> type instance F a b c | b /~ c = Int<br>
<br>
> module B where<br>
> type instance F a b c | a /~ c = Bool<br><br></div><div>During compilation, neither A nor B is aware of the other.  What happens in a module that imports both?<br></div></div></div></div></div></div>