moved a few classes into package expression
created a slot field in UnaryVerbex
renamed verbexLinks to signedVerbex
made SignedVerbex a subclass of Verbex
created interface VerbexWithSubject, implemented by UnaryVerbex and
TripleVerbex (the latter has a compile error);
this is towards creating a Verbex for Frames (whose subject is bound to
the Expression having it as context);
created a Role enum type, implementing the Role interface;
realized that there is overlap between Role and Verbex.Slot, must
integrate the two;
realized that SignedVerbex is different from the previous VerbexLinks:
indeed, the former is a Verbex with a contraint on the possible slot
fillers, the latter merely represents an hint on how a Verbex may be
filled, both classes/concepts should be kept
went back to previous slot making strategy: since it is a glorified
integer, we simply create a new slot every time it is requested
created a new implementation of Verbex where slots are stored instead of
Roles. This avoids the creation of a new Slot everytime slot(i) is
called
note VerbexImpl2 contains a Role reference in each Slot; that's wasted!
Slot can return the static Role reference 
Created a TripleVertex2 according to this principle (it stores a Slot[]
but Slot does not contain a Role, rather the ones in in the static Roles
is returned)
renamed SignedVerbexImpl to SlotLinks because it was rotten.
skeletal implementation of a Frame based on a Frame triple verbex;
subjects to these verbex is constrained to be an expression
introduced asEntity() to wrap an Expression into an Entity, so that a
Frame can make statements about Expressions;
Enabled TripleVerbexFrame to return a definite phrase, by adding a
property value (currently just a dummy, to become a time stamp)
MasterComparator is born. Tries to break symmetry of equals argument
order; grouping together classes that may yield equality or containment
looking for a framework to measure disalignement
replaced Verbex with Verbal
introduced Utils, which contains static methods to create
AtomicEntities; declaring alternative implementation of StringCategory
via a Verbal hasAltImpl, and a static method StringCategory.claim()
trick to distribute comparators to a double hierarchy: the
formalCompareTo method is declared both with an abstract type
argument (e.g. Verbex) and with each concrete type (e.g.
UnaryVerbex). The former is implemented by passing the method call
to the concrete one
renamed and moved ArrayEntity (to Domain.ArrayElement)
added formalCompareTo() code into some Domain classes
changed the name of the formalCompareTo method used in the inner round
to show that double dispatch can't be implemented in this way.
solved the double dispatch problem. It was sufficient to move the first
(outer) call from AbstractDomain into each concrete class. Doing this
made the reference this of a concrete type (rather than AbstractDomain),
so that when passed as an argument it enables method overloading.
Both a version with overloaded method calls inside the concrete class
and inside a Comparator inner class have been shown.