Re: What is wrong with OO ?

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "martin" == Martin ELLISON <martin@mpce.mq.edu.au> writes:

martin> Why can't the compiler optimise the whole program? (Assuming
martin> that it is all written in the same language). Who says that you
martin> have to compile and generate code for each module and then link
martin> them together? Doing so may be quicker for a development
martin> version, but surely a production compile can be optimised across
martin> the whole system.

This is more or less what Ole Agesen has done for type inference in Self
for the production of shrink wrapped applications...

The problem with type inference and OO is that OO modules are supposedly
designed to be as resuable as possible, that is as generic as
possible. Thus type inference returns wide sets of types for
constraints; consider for example a stack class: you can infer that all
variables in it will have a type constraint like 'Object', that is
anything.

Unfortunately such tyep inference is next to useless, for type ifnerence
results in significant safety advantages when type constraints are
narrower, and in optimization when type constrains are narrowest, that
is about a single type.

Since supposedly an OO program is composed mostly of reusable modules,
which are written to be as generic as possible, the situation seems
hopeless.

What Oleg Agesen has done for Self is a kind of type-based ``tree
shaker''; it is base don the idea that if one infers type on reusable
modules *in the context of each application in which they are reused*
then type inference can become significantly stronger (the price of
course one payus to take advantage of it is then code duplication).

So for example a matrix package which is otherwise totally generic can
in the context of a numerical application to be about matrixes of
floats, and in the context of a graphics application to be about
matrixes of integers/pixels.

What then happens is that the whole source of the application is
examined at the same time, and the type constraints of the application,
which are usually quite specific, are propagates across call sites back
to the generic reuable modules that i t references, and these are
specialized for those type constraints. The specialized modules are then
optimized mercilessly as a whole.

This technique naturally has some severe limitations; in practice it is
only useful to develop shrink wrapped, standalone applications, for it
involves a stark tradeoff between code replication and slowness.

Very vaguely similar techniques are used in recent versions of some
``C++'' implementations where template instantion/inlining is in effect
done by the linker in a somewhat clumsy iterative way; or the programmer
does inference by hand listing which templates instances are neded, like
in ``Ada''.

I may be wrong, but the Sather compiler does much the same automatic
process (less clumsily) of global inference and instantiation; in this
is is significantly helped by the rather regrettable limitation which
still exists AFAIK that Sather does not allow separate compilation, so
all modules are merged as _sources_, and (possibly slow) compilation
then on the full source (application plus reusable modules).