> reason I mention it here is the idea that you can run Dylan in two modes:
> a dynamic, interactive, prototyping mode for development, and an
> efficiently compiled, static mode for delivery.  Now for the $400,000
> question:  how difficult would it be to add that sort of capability to
> Squeak?  :)
We have already started !

With Concrete Type Inference you implicitly build a call graph. This is
very easy to do in a procedural language where the name of each procedure
leads to the real implementation. But it is more difficult in a language
with dynamic dispatch (also known as late-binding).

In Squeak a message send doesn't tell you which method will be invoked. You
need to know the type of the receiver first. If after analyzing the whole
program (a starting expression) you got only one particular receiver type,
then you know the method that will be invoked at run-time. You can inline
the method or replace the late binding with a static binding. Cool!!

This is even better that what is done with C++. If you define a function as
virtual, you will always get late-binding through the virtual table.

Having the call graph, allows you to take only the classes and methods that
would be called in *any* execution of that program. This is called
'application extraction' and with this in hand a *real small* 'hello world'
application would be possible.

So, I am confident that an efficent and compact delivery mode is feasible
in Squeak. The firsts steps are taken (take a look at what is done in
http://typeinference.swiki.net). However, this is not an easy task, and
there are some very interesting problems to be solved.

Anyone interested in this subject should read:
- Ole Agesen Phd Thesis. (downloadable from http://typeinference.swiki.net)
- David Grove Phd Thesis. (
http://www.cs.washington.edu/research/projects/cecil/www/Papers/papers.html)


Francisco (Pancho) Garau
Ph: (5411) 4319-6213. Fax: (5411) 4319-6422
garau at ar.ibm.com (work) - - - fgarau at bigfoot.com (home)