Craig Latta writes:
-----
> Sure; I think it's important to keep in mind that the implementation
> provides a certain consistent illusion (of invoking behavior by sending
> messages) but that the scope of the illusion necessarily depends on what
> senders expect to accomplish. These expectations let the implementation
> make certain assumptions, which typically turn into simplifications and
> optimizations. So far, the general expectation senders have of
> ByteArray>>new: lets the implementation make an assumption about the
> parameter (that it's an instance of SmallInteger). If someone comes
> along with a different expectation (such as the one you mention),
> imposing it on the implementation may expose the underlying assumption.
>
> This is always true; for any implementation (containing a "cheat"), one
> can come along with a different expectation which exposes the assumption
> (or "breaks" it). Call it an "incompleteness" property for software,
> similiar to the sense of incompleteness in Gödel's theorem. You're
> trying to play a new phonograph-killing record. :)  (Hofstadter 1979,
> you've probably read it, everyone should...). And you can always come up
> with a new cheat the restores the illusion to match the new expectation.
> Luckily, we can always do this with Squeak, although perhaps not with
> the performance we would like. As you suggest, we can also change the
> client to work around the limitations of the implementation, but I agree
> that this is undesireable (because it overcomplicates use of the
> system).
>

I read and enjoyed Gödel, Escher, Bach when it was new so I'm having
troubles remembering what it has to say about always getting caught cheating
(in the sense we are talking about). Maybe a few sentences expanding upon
why there is the "incompleteness" property would be helpful.

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.  As Dean
Tribble writes in section 1.3.5.

"Complete virtualizability is one of the primary mechanisms for com­posable
orthogonality. Because clients can only interact with servers by passing
messages, other servers (middlemen) can be interposed between a client and a
server to add functionality without requiring a change to either the client
or the server. Virtualization only aids composability if it is complete: if
programs behave differently in the presence of middlemen that weren't
intended to change the behavior, then middlemen cannot be transparently
added. Complete virtualiz­ability enables transparent layering of
functionality: servers only affect each other in intended ways. "

So either I and the authors of these other languages are confused or else
this "incompleteness" property can be avoided with the right protocols and
implementations.

Best,

-ken kahn ( www.toontalk.com )