1. Is there any documentation about this modularity?
   
2. Does a discussion about the modular dessign concepts exist?
   
3. Is there any intention in adding non-compile-time communication layer plug-ins?
   

First of all the compile-time FBs will not go away. This whole idea about being able to add new FBs to a compiled FORTE without the need for recompiling a new FORTE is driving us since the original developments of FORTE long before it got open sourced. In 2005 I supervised a master thesis by Domenico Rubini at Vienna University of Technology where such concepts have been evaluated. At that time we considered developing our own VM based approach. This was very hard to maintain therefore it never made it in the open source version. But the general design of FORTE was always to accommodate modularity on FB level. This is also a key design element for the C++ based FBs.

Later on guys at Profactor experimented with Lua as potential implementation language and execution environment for FBs in 4diac. Michael Hofmann and Gerhard Ebenhofer have published some papers at ETFA conferences and there are also presentations at 4diac users' workshops. This work has been taken up by colleagues of mine at fortiss and currently we are expanding this concept and experimenting with first prototypes. Unfortunately there is appart from the above mentioned not really any documentation available. Currently it is also not in a state that it is usable by the general 4diac user. We hope to have more ready by the next milestones (probably 1.9.0-M3).

For now the work is focused on providing an environment dedicated for FBs. That also means that we are restricting the Lua environment only to these needs. Lua generation and deployment will be integrated in the download functionality and therefore mainly invisible to the normal 4diac user. The main advantage is that users don't need to install compilers but can work with pre-compiled FORTEs.

Sofar we haven't thought about other use of Lua then FBs. And as we still see quite some work on our main use-case we'll focus on that. Also to learn and gain experience on how to use Lua. From that on further usage of Lua could be interesting.

My thoughts were not involving VMs or removing C++ FBs. I was thinking about the possibility of compiling the runtime first, and then compile FBs or communication layers afterwards without the need of recompiling the whole runtime. This would also allow to select at a finer granularity which FBs are needed in each runtime, which would allow more constrained devices to save disk space. Obviously, in such a design a subset of the FBs could be compiled with the runtime too if they are considered to be "required". In conclussion, I was not thinking on removing modularity at compile time but adding modularity at any time. And by modularity I mean C/C++ compiled FBs, not interpreted ones (which is also a interesting but different feature) such as those in LUA.

I understand the LUA interpreter gets compiled when the runtime is, and that what you said about "generation and deployment" is about LUA scripts. Also, what does "generation" mean here, are you talking about auto-generated code or does the application developer need to program it? Will there be some kind of LUA FBs library such as the C++ FBs library there is now or is it just intended for people with scripting knowledge?