intention of having "messaging semantics that are described entirely in terms of those same objects and messages" is not attained.
Not entirely, no. The statement tacitly assumes that the ABI will not have to change, which precludes extending the context of method execution by way of additional implicit method arguments. This is the reason _bind() and _send() had to change, since they introduced a new hidden argument in the ABI (splitting 'self' into a pair of arguments: the 'receiver' and the 'state fragment'). I should change the quoted statement to be more restrictive.
That being said, redefining lookup is almost enough. Something very similar to the code in Section 2.2 of http://piumarta.com/software/ cola/objmodel2.pdf would work, and would support multiple delegation, provided the new semantics need only a single 'self'. Either the identity of the original receiver can be preserved as 'self' (and composition is not allowed to introduce additional or refer directly to state) or 'self' can be rebound to the fragment that implements the destination method (and sends to 'self' will no longer be referred back to the original composite receiver).
'Leiberman' prototypes require both 'selves' to be present in the destination method. I think the only way to build a completely extensible system (with respect to both the internal ABI and foreign calling conventions) is to have runtime control over the ABIs of interest, hence all the (dynamically-compilable) lambdas pointing at the intrinsic method invocation and sequencing parts of the diagram in the COLA whitepaper. (Controlling the scope of customised ABIs is probably a much harder problem than providing the customisation itself.)
Send site descriptors (that have been discussed here on several occasions) can solve many of the internal ABI problems, but by no means all of them. However, I think they would be sufficient for Leiberman prototypes provided 'receiver self' was communicated to the destination method exclusively through the descriptor and the descriptor was made available to, and could be extended from within, lookup.
Cheers, Ian _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
