Good Things About E

[Mark S. Miller]

At 12:25 AM 10/19/98 , Ka-Ping Yee wrote:
>The following thoughts have been in my mind about E for some
>time and i'm sure they are obvious to everyone already, but i
>thought i would just put them down here to solidify and verify
>them.  I would really appreciate if someone just lets me know
>if i've got the right picture here.
>
>
>E objects are like lambda closures with methods.  They are just
>like lambda, but instead of knowing how to do only one thing,
>you can choose which of many actions they will dispatch to.  An
>E "function" (object with just a run() method) is a lambda.
>
>Each object remembers its binding scope, the scope in which it
>was defined.
>
>E doesn't have the particular feature of Python where you can
>reach into an object and take out a method as a separate
>function object, or where you can take a function and stick it
>into an object as a method definition.
>
>This sort of flexibility can still be achieved if the object
>wishes to allow it by delegating specific messages to another
>object (representing the function you wanted to put into the
>method slot).


[+] Exactly!!


>But the strictness which comes from knowing all the methods at
>definition time: (a) means you can verify security by looking
>at one short piece of code and (b) means the compiler can
>optimize method calls knowing that they will never change.

[...there followed a discussion of why Python could not optimize method
calls into typically being straight jumps...]

[+] While #a is true and important, 
[-] #b is only true for naive implementation approaches.
The Self virtual machine is able to maintain Python-like dynamic
modifiability while providing performance often exceeding C++.  The well
known Self technique is dynamic optimization -- filling the code cache with
inline-optimized sequences for the paths through the code actually taken.  

The support for dynamic modifiability is a less well known, but equally
important, technique they call dynamic de-optimization: invalidating the
parts of the code cache made invalid by changes to the source.  (The hard
trick is to do this while maintaining the semantics of execution in
progress.)  Execution then causes the code cache to refill, by dynamic
optimization, with optimized code consistent with the new state of the
sources.

But what can you expect from a language implementation (Python's) that
still uses refcounts?  ;)

	--MarkM, expressing Self interest