Some of these will be final once decided for each weaver implementation while others can be up to the user to decide, using the aspect or some other mechanism to indicate this.

This is in respect to the generation of new code, from scratch or from transforming templates. Code can be generated at weaving time and execution time.

If the code is generated at weaving time, then there will be multiple versions which are compiled. They can be included in the main binary or compiled as dynamic libraries which are included as needed during runtime.

If these versions are generated during the execution, the easiest way to integrate them inside the application is to compiled them as dynamic libraries which can be included on demand once they are needed.

The interpreter can be embedded in the target application or it can be outside (possibly) in a remote machine. In this case, the communication can be performed using, for instance, message passing interfaces (MPI, 0MQ) or files / pipes.

The interpreter can be running using native code or JavaScript. If it runs native code, the LARA aspect (with JS) needs to be translated to the application target language, e.g., Java or C/C++. On the other hand, if we assume there is a JavaScript interpreter it can directly interpret the JavaScript code that is generated from the Aspect-IR.

The interpreter (decisions, code generation and so on) can be executed in sequentially in the application or in parallel.

These can possibly be replaced by aspects. If this is true, we may still consider having a monitor expression simply as syntactic sugar.

It is possible to generate new versions and call them at execution time by using shared libraries (.so in Linux and .dll in Windows). These can be linked and loaded on demand, during the execution.

Some useful links on how to create these libraries and link/load them at execution time on Linux:

• Shared libraries with GCC on Linux
• Yolinux.com Tutorial Static, Shared Dynamic and Loadable Linux Libraries