Compilation by parts

[kasperdokter]

The current compiler takes the following steps:

1. reads multiple Treo source files;
2. filters out the protocol components from boundary components;
3. composes the protocol and generates a runtime component for it;
4. wraps all boundary components into a runtime component; and
5. outputs all runtime component.

In this framework, there is always exactly one runtime component generated for the complete protocol. The code for this protocol component may depend on Treo code that may come from any possible Treo source file. Therefore, it is not yet possible to compile individual Treo source files using the current compiler.

The user of the compiler might want recomile quite often. Since most files remain exactly the same between two successive compilations, the compiler should be able to reuse its previous results to save time and energy. Especially for large projects, such efficiency step is very desirable.

To allow the reuse of previous compilations, the user should restrict the number of Treo source files on which the protocol's runtime component depends. In that case, all Treo source files that are not used by the procotol can be compiled independently.

One possible way to restrict the dependencies of the protocol's runtime component is by isolation of part of the protocol, that is, ensure that a part of the protocol does not end up in the same runtime component as the rest of the protocol.

Currently, the user can achieve isolation manually by putting the part of the protocol that needs to be isolated into a fresh boundary component. However, this requires the user to precompile that part of the protocol, and write a wrapper Treo component for that generated protocol code. This refactoring step (of converting a Treo file into an boundary component) is quite labour intensive, and should be automated.

One possible way to automate this refactoring process is it to extend the Treo language and by altering steps taken by the compiler. Essentially, the user should be able to determine which parts of the protocol should be treated by the compiler as isolated components, and which parts may be freely composed and optimized.

We could enable the users to declare which parts are isolated by extending the Treo language as follows: If we wish to use a component, then we use

• the include keyword, if we allow it to be composed with the rest; and
• the import keyword, if we use it as an isolated component.