<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">> apparent vs. actual type<br><br>I've seen these terms used in OOP contexts, but I was using them somewhat <br>informally here. I mean that dispatch should be based on what you know of the <br>types locally (lexically). Or simpler still: instance selection should be static and <br>not dynamic (though with this phrasing there is a caveat that with existential <br>types the static instance chosen is arguably a dynamic dispatch).<br><br>> The problem is that I, as a caller, cannot alter what was in scope at the callee <br>> after the fact. This means that it is sometimes impossible for me to introduce<br>> new specializations for new types.<br><br>Agreed - the caller cannot alter what was in scope at the callee. This is <br>important, since the callee code relies on the instances it has chosen for its
<br>correctness. If the callee code isn't abstract or polymorphic enough, it would <br>need to be fixed.<br><br>The only problem I see here is that the conventional notation for type classes (a la <br>haskell) is sufficiently verbose that it discourages making code as fully abstract as <br>it could (should) be. That, and problems related to inefficient separate <br>compilation in the absence of link-time specialization.<br><br>Matt<br></td></tr></table><br>