New Script Architecture

[giovinazzo-kevin]

Since Ergo has moved to a VM-based architecture, Fiero scripts must be refactored to exploit it efficiently.

Besides, there was already some spaghetti going on with ScriptEffectLib. I need to come up with an architecture where scripts and effects are managed correctly.

[giovinazzo-kevin]

See also #14.

The current architecture essentially works like this:

• When the Script entity is built, the corresponding script is loaded or retrieved from the cache.
  • This script has its own knowledge base that is shared with cached copies having the same cache key.
• When a ScriptEffect is Started on an Entity, a new context is created for that entity.
  • A ScriptEffectLib is dynamically generated and bound to that context in the script's entry module
  • This requires manually asserting its builtins because the knowledgebase has been built by now
  • This library captures the owner, the script's arguments, as well as some other local data, and exposes builtins to retrieve them and to control the effect

Now, since the addition of a compiler, the dynamic loading of ScriptEffectLib has become problematic. Ideally, all predicates that a script needs should be made available by FieroLib and ScriptEffectLib should be removed entirely.

These predicates should act on the script's state which is asserted in its knowledge base when it starts.

Resolving this issue requires devising a mechanism to link knowledge bases (and their dependency graphs) together, so that each link can be managed independently. This way, each instance of a script can link to the same underlying knowledge base, without asserting its own state there.