Hi Craig -
>
> > As I recall the early actor languages (Plasma and Act 1) had no such
> > problem. And a more recent example is Joule
> > (http://www.agorics.com/Library/joule.html). In particular see the
> > section 1.3.5 on Complete Virtualizability in the Foundations
> > chapter.
>
> Hmm, I'm unfamiliar with all of those. Thanks for the references!
>

Plasma and Act 1 date back to the 70s. For Act 1 see Henry Lieberman,
Concurrent Object Oriented Programming in Act 1, in Object Oriented
Concurrent Programming , Aki Yonezawa and Mario Tokoro, eds., MIT Press,
1987 which can be found at
http://lieber.www.media.mit.edu/people/lieber/Lieberary/OOP/OOP.html#Concurr
ent-OOP-in-Act-1. Here is a little info on Plasma:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?PLASMA

>
> My sense so far is that, like the Tortoise in Hofstadter's fables, one
> can always devise an application for a software system which breaks the
> continuity provided by the implementation. I think it's a very
> interesting hypothesis; I'm interested in thinking more about it.
>

I agree it is interesting and I see better now your analogy with Gödel's
theorem. I can see a few very different ways of devising an application that
can tell apart a primitive object and a behaviorally equivalent one.

1. As someone pointed out in this thread the virtualized object needs to be
able to give to the implementation of some primitives a primitive version of
itself. In Act 1 I think there was a message that asked for a "rock bottom
actor". If this message can be sent by any code then maybe one can test the
identity of an object and the result of asking it for its rock bottom
version. This then depends upon how you test object identity as to whether
this will work.

2. You can write code that tries to see if more resources (CPU time, memory,
network usage, etc) are used by the suspected virtualized object than the
primitive equivalent. In a multi-threaded environment you might have to do
multiple tests and can only be statistically confident that you can tell
them apart.

3 Sometimes facilities that are intended for use by debuggers and the like
can be abused to tell a virtualized object apart from its primitive
equivalent.

I think a well-designed language can avoid #1 and #3. #2 can be used to
break any kind of polymorphism, right?

While there may be a kind of "incompleteness" property here as you suggest,
it may be that it doesn't apply to any "reasonable" code (e.g. code that
wasn't written with the purpose of behaving differently when receiving
primitive objects).

Best,

-ken kahn ( www.toontalk.com )