OIL review ?

[Pawlak Renaud]

Hi everybody!

My name is Renaud and I work with Laurent on OIL. I've been following your
discussions for a few weeks now but I've been too busy to talk. However, since
Jim made a very useful critique of OIL, it seems that it is time to break
silence and to complete Laurent's answer by explaining how and why OIL project
is useful.

First, OIL's final goal is to fully support Aspect-Oriented Programming. I guess
you have already heard about this but since definitions may be not well fixed or
equivalent in everybody's mind, I prefer to give a brief definition of what we
mean, Laurent and I, when we talk about AOP.

To us, AOP consists in 2 steps:

- first step : specifying (or programming ---we do not make any difference), the
application or a usable object semantics.
This first step has to be done in a specification language that can be a general
purpose one or a domain specific one (depending on the nature of the program).
To us, this specification does not implies that it exists an implementation (the
program is not always runnable). To run the program, you need a interpreter able
to understand the specification language. Depending on the abstractness of the
language, it will be more or less easy to implement a generic interpreter that
will be able to run the program.
For example, it exists a lot of generic interpreters for functional programming,
but, those for mathematical specification are quite specific or inefficient.
Thus, the AOP introduces a second step which goal is to tune the interpreter
implementation so that it can be specialized for a given program written in a
given language. This tuning is done in some new program entities that are called
ASPECTS.

- so, the second step consists in writing the aspect programs that modify the
interpreter implementation untill it is efficient for a given language/program
category/program.
Generally, the aspect programs do not change the base program semantics (they
just make it run faster). However, it also exists some kind of aspect that
change the program semantics by extending the specification (for example by
adding security or transactional features). Despite we want to strongly
differentiate this kind of aspect (semantic aspects) and the first kind
(implementation aspects), we also need to use them because they bring useful
separation of concerns.

I hope that it makes more clear about AOP. Let's now talk about OIL.

Because OIL should implement AOP, it needs to contains at least one default
specification interpreter (that can run user programs), and a way to implement
aspect programs that could tune this interpreter. In existing Aspect Oriented
Systems (like AspectJ), introducing aspects is done in a limitative way and by
using pre-compilers (so that the final VM is still a standard Java VM). Since we
do not want to limit our specifications to Java (or any other language)
programs, we want the aspects introduction to be builtin in the interpreter.
Thus, we need to extend an interpreter so that it can understand some
optimization asked by the aspect when executing a program.

However, most of the existing interpretors already have builtin specific
optimization features that complexify their code (in fact, that's because
separation of concerns is hardly achieved in traditionnal programming and it is
difficult to separate the fonctionnal specification of the interpreter and the
optimizations --- these should be, in AOP, exclusively made in some aspect
programs). Of course, we don't want builtin specific optimizations ; we want to
apply the same principles AOP to the interpetor development as we use them for
programming

This is the main reason why we decided to program an entirely new interpreter
(not too much optimized since this will be done within aspects). Another reason
is that we wanted to implement a general pupose specification language so that
we can specify any other abstraction with it (ok, it is not so far from Lisp but
we didn't know at first).

But we have to anwser one tricky question: how can we apply AOP to the OIL
default interpreter program since is is written in C????

The idea is to implement a minimal bootstrap interpreter in C called I0 (this is
what we are doing currently) and then re-implement it in OIL (so that the
interpreter I1 is clearly specified in OIL and can be interpreted by the
bootstrap interpreter). Thus, an OIL program P can be interpreted in 2 ways :
- by I0 : I0(P)
- by I1 (which is itself interpreted by I0) : I0(I1(P))

Because I0 and I1 are equivalent, interpretation results are equal : I0(I1(P)) =
I0(P). However, as expected, I0(P) runs faster than I0(I1(P)). So we would
rather interpret P with I0.

Since I1 is done and is clearly specified in OIL, we would rather now work on I1
if we want to modify the interpreter (and, don't forget that it is the goal,
introduce aspects). However, if we modify I1 into I1', there will be a problem
because : I0(I1'(P)) != I0(P). So we cannot use I0 any more and we must
interpret P with I0(I1'(P)) that brings very bad performances. A solution to
this is to introduce a meta-circular link between I0 and I1. This means that I0
and I1 are causally connected, ie each change done on I1 is also done on I0.

To do this, we introduce a compilation process that compile the I1 from OIL to C
and replace the I0 interpreter so that I0 is always the exact copy of I1
(functionnally speaking).

Notice that the compilation engine will be written in OIL and should only be
written once.

Next, we will modify I1 to introduce the possibility to add aspects to the
program P so that we can tune its interpretation like this:
I1(P, A1, A2... AN)  where An are aspects that will be  able to add some useful
optimization techniques like, code transformation, partial evaluation,
caching...

But, since I0 = I1 (thanks to compilation), the fowllowing will be ok :
I0(P, A1, A2... AN)

Thus, we will also be able to optimize I1 with some aspects (because I1 is an
OIL program like P):
I0(I1, A1, A2... AN)

And because I0 = I1 after compiling, we have manage to optimize I0 with AOP
techniques (and not with classical ones).

To sum up the OIL project phases:
- bootstrap interpreter (I0) implementation in C (finished)
- I1 implementation in OIL (to be started really soon)
- implement meta-circular link (compiler)
- add aspects to I1 (and so to I0)
- optimize I0 by optimizing I1 with aspects

I hope that it clarifies some questions about OIL. I belive that it explain why
OIL still does not implement any AOP features.

Do not hesitate to ask me any question or to send me any remark.

PS : Notice that this mail was on OIL implementation steps, we will define what
we will exactly put into aspects in futher works.


--
Renaud Pawlak, PhD Student CEDRIC-CNAM Laboratory.
Phone : (00 33) 06 60 92 64 17.
Home Page : http://cedric.cnam.fr/personne/pawlak.