<div dir="ltr">Thanks for the comments Jed and Matt, I'll defer to your judgement regarding the implementation that is the least intrusive. I'll take a look at this later on when I have time.<div>Colin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 12:29 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
> I don't like this business of ISes holding pointers to other ISes. This<br>
> fundamentally<br>
> changes the model. The hashing sounds workable.<br>
<br>
</span>ISs are immutable and a reference would probably be held anyway, so I<br>
don't think it's evil.<br>
<br>
We also have to think about recursive composition and I'd rather not<br>
have to walk a subset DAG.  If we hash, the IS would just store a list<br>
of "known subset hashes" with the semantic<br>
<br>
  (A ∪ B).known_subset_hashes =<br>
      A.known_subset_hashes ∪ B.known_subset_hashes ∪ [hash(A)] ∪ [hash(B)]<br>
</blockquote></div><br></div>