Skip to main content.

Sunday, March 25, 2012

... And after more or less one year since we started the new engine development, we finally have completed the whole of the engine logic. The last entity needed to have a somewhat complete engine, where everything can built upon, that is, the module serialization, has been achieved a few hours ago.

Why did it take more than one year to have a "simple" thing as a skeleton of module serialization?

The reason lies in the way the new engine is conceived and developed. Although it is universally known that one rule of good design is to start with simple things and add modular complexity as things get nastier, this approach was simply not viable in the case of the new Falcon engine.

Mainly, we have three logic entities that are intertwined into a single, irreducible unit:
- The organic virtual machine
- The class-delegated data model
- The syntactic tree code definition

The virtual machine runs the syntactic tree, which operates on the data, which is then stored in the virtual machine. The syntree entities are reflected as data via class-delegation, and then the VM can manipulate them as data or execute them as code.

Besides this nuclear intertwined entities, the garbage collector, the storage system, the compiler(s), the Virtual File System and other minor ancillary entities interact more or less deeply with the central core of the system.

To be sure that this reflexive architecture could be working, it was necessary to bring it to a quasi-complete development stage. Solving just one of the numerous problems and challenges that are involved into this massive central core wasn't enough, as it wouldn't have been possible to use the success as a step towards further achievements. Or, said otherwise, it was an all-or-nothing bet.

We got all.

For instance, the Module class, which is responsible to present a module to a script, (i.e. finding Mantras on dynamic requests, adding or removing them dynamically etc.), is also in charge to provide the serialization layer with all the code needed to store any entity in the module. The serialization system itself is exposed to the scripts, and can be used to send arbitrary data, or code, or data and code entities anywhere in the world, or store them on any stream. The pre-compiled module that is stored in a fam file is the same thing that can be created in a script directly with a couple of statements. The data structures in the module, as the classes, could be inspected and changed, and the code, the functions, might be dynamically created or altered.

The module is then just an organized container that interacts with the Falcon linking system, so that foreign code can be automatically invoked, or so that forward declarations are served to the scripts through the help of the engine. But otherwise, it's an unnecessary entity, as you can dynamically create, inspect, alter, run and destroy any code from anywhere.

This is reality now.

There are a few secondary issues I want to take care of, to complete the public API; should be less than one day work. Then we have just to complete the engine withe a few constructs (switch and class states still missing), and we can move to the alpha release.

Comments

No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it