On Sat, Feb 13, 1999 at 06:03:37PM +0100, Joachim Durchholz wrote:
>   SmallEiffel (named in honor of Smalltalk actually) goes about by doing
> something that I call "type-flow analysis". IOW it looks at all object
> creations and does a pessimistic data-flow analysis about which point of
> code these objects may ever reach. For methods that are known to be
> called only for certain object types, dynamic dispatch is entirely
> replaced by static calls (and a typical program can staticize about 90%
> of calls). Calls with few (about two or three) alternatives are done
> with an if-then-elseif...else construct. These things allow more
> advanced optimizations, like call inlining, low-level data-flow
> analysis, and peephole optimizations (not all of them actually in
> SmallEiffel).

Similar optimizations can be done at runtime, and thus even in a
dynamic language. The "Type flow analysis" done by the Eiffel compiler 
is somewhat similar to a simulated execution of the code. So you could
gather the same information in the running program. 

Something like this is used by Self. First the methods are compiled with 
a fast, non-optimizing compiler. At runtime the system analyses program 
flow, and if the method is called more often, a second, very smart
optimizing compiler steps in and recompiles this method with the help
of the runtime-information.  

The problem with the "runtime approach" is that the VM needs some
"warm up period" to analyse and optimize the running programm.

>   Ah yes, and now the most interesting (and controversial): Numbers. A
> typical SmallEiffel program has dynamic dispatch removed for about 90%
> (!) of all calls. 
This is exactly what the Self-VM can do at runtime (in the avarage case).
(according to: "The Self 4.0 Userinterface: ....." available somewhere
at the self homepage)   

> Images can get as small as 4 KB (when all error
> checking is removed; still included is a run-time system with garbage  
> collection and dynamic dispatch). This is regardless of the size of the
> standard library involved; anything that isn't needed is pruned out.
> Of course, these optimizations are at the expense of extendibility.
> You cannot add a class to a running SmallEiffel system. You have to name
> a top-level class with a feature that will be called on system start-up,
> and the system will stop when the feature is done.

http://www.sunlabs.com/techrep/1996/abstract-52.html

       Concrete Type Inference: Delivering Object-Oriented Applications 
       Ole Agesen 
       TR-96-52 (January 1996) 

| Abstract
| .....
| We have designed, implemented, and evaluated an algorithm, .... , that
| can infer concrete types of object oriented programs. ...
| Our implementation handles most of the dynamically-typed Self
| language,... 
| ....
| Using the inferred concret types, a compiler can statically bind and inline
| message sends, a browser can follow control-flow through message sends, an
| extractor can identify the essential objects for an application and
| discard the rest, and a checker can statically garantee the absence of 
| message-not-understood-errors. ....
|
| .... the shrink-wrapped application comprises 350Kb, a 96% size reduction
| over the original 10Mb image. ....

I haven't found the time to read past the abstract. (The whole thing
is 170+ pages...). Somehow this "type-inference" looks like black magic... 
I want something like this in Squeak!

[pre / postconditions]

Smalltalk: a reflective language. by Fred Rivard 
(http://jerry.cs.uiuc.edu/reflection/reflection96/docs/rivard/rivard.html)

|... in the second part of the paper, we introduce fully developed pre/post
|conditions on smalltalk,... 
 

 Marcus

-- 
Marcus Denker marcus at ira.uka.de fon at home:(0721)614235 @work:(0721)608-2749