
               Changes from Algernon v2.0 to v3.x



These characteristics of the AAM are *not* backward compatible
with previous versions of Algernon.  


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  Binding Environment  (16 Sep 1996)   AAM v3.5
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  When processing paths containing :A, :THE and :FORC variables,
  only the primary variable of the form is visible outside of
  the clause.  For example:

   ((near Me ?you)
    (:A  ?thing 
         (near   ?you ?thing)         ;; nested environment, so ?you is visible
         (beside ?you ?something)     ;; ?something is only visible in :A form
         )
    (around ?you ?thing)              ;; legal
    (around ?you ?something)          ;; Illegal
    )



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 :A syntax  (16 Sep 1996)   AAM v3.5
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  :A no longer accepts multiple assignment variables as in
     
     (:A  (?var1 ?var2) (...))

  Instead, it accepts only one variable, and the variable may
  optionally be specified as a member of a set.

     (:A  ?var  (...))   or   (:A  (?var <set>)  (...))

  For example,

     (:A ?rover (name ?rover "Rover") (isa ?rover Dogs))

  is now more concisely

     (:A (?rover Dogs) (name ?rover "Rover") (...other forms...))

  which expands to:

     (deftaxonomy (Dogs Rover))  ;; And binds ?rover to the appropriate frame



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Compiling multiple versions of if-needed rules  (16 Sep 1996)   AAM v3.5
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  When compiling an if-needed rule such as:
 
     ((rel ?x ?y ?z) <- (...) (...))

  it is unknown at compile time which of the variables ?x, ?y and ?z
  will be bound at rule activation time.  The compiled code generated
  for a specific instruction often depends on whether a variable is 
  known to be bound.  To handle this, the compiler generates several
  versions of the compiled form of the rule for various sets of bound
  variables.  If, at runtime, it runs into a bound/unbound variable
  configuration that it did not anticipate, it will compile yet another
  version of the rule (compilation is nearly instantaneous).

  Since the user may never intend for certain configurations
  of unbound variables to occur, the compiler may generate spurious
  "access limitation error" warnings during compilation of these
  alternate rule forms.  These messages are sometimes spurious, but
  may also be genuine, so the programmer is encouraged to read the
  warning messages closely.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Disjoint taxonomic subsets  (15 Oct 1996)   AAM v4.0
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  Sibling subsets of a taxonomy are now declared disjoint, and 
  assigning an instance to one of the subsets now causes it to
  be declared as "not an instance" of the other subsets.

  For example, (deftaxonomy  (physical-objects
                                (animals
                                  (Dogs  Rover)
                                  (Cats  Sam))))

  asserts:

     (isa Rover Dogs)
     (not (isa Rover Cats))
	
     (isa Sam Cats)
     (not (isa Sam Dogs))


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 :STOP command  (23 Oct 1996)   AAM v4.2
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

(:STOP) will halt execution and return to the user level.

 It is useful, for example, when searching for just one solution.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Constrained rule activation  (12 Oct 1996)   AAM v4.3
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Given a query:  (rel ?x ?y ?y)   and rules of the form:

  ((rel ?a ?b ?c) <- ...))

there is a question of whether the rule should be constrained
at activation time so that ?b and ?c have the same value. 
In Algernon v1 and v2, the rule executes unconstrained and the
returned values are filtered ex post facto.  

In Algernon v3, the rule is constrained at activation time
and will execute as though its consequent is (rel ?a ?b ?b).

This is implemented by substituting dummy variables into
the executing rule.  The user may encounter these dummy
variables if they fall into the debugger.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Compile-time slot type checking  (16 Oct 1996)   AAM v4.3
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Algernon checks every slot reference for correct argument types.
Algernons v1 and v2 do this at runtime.  Algernon v3 does it 
when compiling each rule or path.  This provides for faster
runtime and earlier detection of errors.

However, this means that the KB components should be defined
in the following order:

  1) taxonomy
  2) slots
  3) rules

The compiler propagates types by inferring a variable's type at its first
reference, and then assuming that type for all subsequent references.
The first reference in a rule may be the first clause of the consequent 
(for if-needed rules) or the first clause of the antecedent (for
if-added rules).  

Subclasses are supported.  For example, if the first reference of
a variable gives it the type 'DOGS', then a subsequent reference
that requires a type of 'MAMMALS' would be allowed (assuming the
taxonomy defines a subclass relationship between DOGS and MAMMALS).
However, the reverse would not be allowed.  This is equivalent to 
the type propagation allowed in O-O languages like C++.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Asserting types of slot values  (07 Feb 1997)   AAM v4.x
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In earlier versions of Algernon, asserting a value into a slot 
would also automatically assert an ISA relationship between the 
value and the type of that slot position.  For example, the
slot:

   (:slot  pet  (Humans Animals))

and the assertion:

   (pet Fred Rover)

would automatically assert:

   (isa Fred  Humans)
   (isa Rover Animals)


Over the course of a long run, these assertions were performed
repeatedly, and were wasteful in terms of the computation they
required.  Algernon v3 no longer makes these automatic assertions.

It does perform compile-time type checking on the arguments of 
slots to ensure that they are consistent within the body of each rule,
however that does not ensure run-time consistency of the KB.
