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