Progress Meter

- [WIP] Knowledge-Representation Improvements
  - [X] Better syntax, cleaner API & refactoring
  - [~] Meta info in slots
  - Advice
  - Multi-Methods (value-based)
- [WIP] Constraint Management Improvements
  - [X] Better syntax & some refactoring
  - Parameterized pointer variables
  - Advice (for constraints)
  - Store constraints as KR objects
  - Async execution
  - Change predicates
- 2D Graphics
  - Linear Algebra and Geometry additions
  - 2D API for geometry + Backend (via SDL)
  - Event objects + Backend (via SDL)
  - Text API + Backend (via Pango)
- Cells
- Configurations
- Some demo (after everything else)

---

A quite solid month, the major changes can be summarized as:

- Some essential solver data structures have been replaced/refactored.
- The inheritance model has been fully rewritten and is now based on constraints.

First of all, the Sky-Blue solver was using a couple of
poorly-implemented data structures, among a few other things. All these
had to be attended to. As a result, by some basic benchmarks, the speed
has improved 2-2.5x overall.

I have also decided to disallow conflicting strengths for constraints
that write to the same variable. Allowing these would mean relying on
the order of addition, and therefore execution, and that's something
that could be hard to reason about. It seems it best to just require the
code authors to define a clear ordering of things before any bugs creep
in. And constraint strengths as such are now simply integers, not a
limited set of ordered keywords.

Second, it appeared to me that the way I did inheritance, while being
bug-free otherwise, would be hard to make work well with constrained
slots. In particular, the order of execution and recomputation would be
a bit tricky to control, i.e. when you change some slot in the parent
schema and the value has to propagate to the children.

Now, it seems obvious in retrospect, but modeling inheritance via the
constraints themselves is a much simpler and more consistent
solution. The way it works is basically such that a slot in the child is
constrained to be equal to that slot in the parent. Assigning the
appropriate strengths to these connections preserves the hierarchy in
case of multiple inheritance, routinely takes care of the ordering and
the value updates.

The new model pretty much has all the necessary features already, it's
fully dynamic, potentially extensible, and the user can both inspect and
remove/filter any particular connections (and in the future: advice them
too, since they are just regular constraints).

It took a bit of preparation, but the resulting code for all of
inheritance is now contained, rather simple and is only ~130LOC. And
while that's pretty good, I have a feeling this just might be reduced in
the future if it makes use of parameterized pointer variables
(e.g. constraints that map to multiple slots, a yet-to-be-implemented
feature). In fact, I think the new inheritance solution just might guide
that work quite soon.
 
So at this point it's not so much some frigid concept of inheritance in
its usual sense as much as simply a case of hierarchical data
consistency management. And, it seems to me, that's exactly what it
ought to be. Quite importantly, as a result, there's now no need for any
coupling with the internals of the constraint-integration code, as was
necessary with the previous approach.

---

The next steps are to restore/revise the relevant tests, but that won't
take long. Otherwise, the foundation now seems quite ripe for the next
immediate targets:

- parameterized pointer variables;
- constraints as KR objects, with some form of schema-like access semantics.

The former of these should yield a quite powerful and indispensable tool
for dealing with multitudes of slots.

The latter objective should result in a consistent interface for
deriving/cloning/modifying the constraints.

Best,

  -- DK