New details for the base code.

[Giancarlo Niccolai]

Recently, I have been working at the base code we need to start programming Falcon2. On one side, I am studying the new stuff in C++14/17 that we might want to use, on the other I tried to solve the basic problems that had always been a pain in the neck in the older incarnation of the engine. 

Here some of the solutions I came out with:

1. New item structure: shall simply be a pair of class pointer and data pointer (or actual data for flat types). Modern architectures can compare-exchange a pair of pointers in an atomic operation natively, and while the PP (parallel processing model) I have in mind don't require ever-present item-level atomic updates, there will still be atomic item updates in some occasion. Being able to update shared items atomically without locks, spinlocks or update loops is still a very important improvement on the previous lock model.
   
2. Nilling: With this simple item structure, it's now necessary to have class Nil which is the only indicator of an object being nil. Previously, the type was stored in the prefix of the item, and storing a zero there would have been enough to nil the items. With the new model, we need to write the pointer to the Nil class to all the areas that are "zeroed" in the virtual machine. However, with the item as a pure pair of pointers, we can simply write the pointer (twice for each item) instead of zeroing the memory, which is equivalent on modern architectures (it's still a rep movq instruction).
3. Binary operators. Without the item type pair being used as a switch case, we cannot implement the binary operators for simple types as we did before, nor I'd like to. That was the thing that kept me up at night for a couple of weeks now, until I found a way to make it fast in the easy cases and flexible as we need to have it. With an emphasis on aspect programming, we cannot even rely on the "class", as any item might have a different delegation scheme (i.e. even a "string" might have a "+" operator overloaded differently with respect to a factory brand new string...). I solved this with the idea of relational programming: the first operand selects an available value type from the second, sending a function in form {@value => ... do things with @value...} to the second operand, or in other words, we put the second operand in a typed relation with the first. At low level, the class will have a no-op for simple cases, for example, the class Number will just return an integer if the relation asks for the value @int.

This third point is the last thing I needed to clarify to myself before starting planning the engine development. 
Before proceeding with the code, still in the planning area, I still need to solve two problems:

1. How to expose the engine across dynamic library barriers. This is actually a problem just on Windows (DLL and templates do not go well together), but it's a big problem. The previous solution of having our own types going back and forth from the engine to the user program is still valid, but I want to see if there is any other way.
2. I'd like to have a solid grammar to represent relations and concept values. The example I gave in my previous mail, with concept values "seen" as specially marked parameters for funciton/closures, like { @concept_value, other_param => ... } is not bad, but with things like the ability to present a different view to binary operators (point 3 above), it may be worth to think at a generic way to express concept values.

In short, I am still working out the abstractions, but I am getting closer. I think I can start coding within a month.