Role

Inference libraries

Introduction

Simple forward-chaining proposition inference can be coded directly in GRL using the built-in logic primitives and, or, etc. For example, the implication

near-the-object Ù facing-the-object Þ the-object-is-grippable

can be expressed, assuming the truth values of antecedents have been computed somehow, simply by saying:

(define-signal the-object-is-grippable?
  (and near-the-object?
       facing-the-object?))

or:

(define-signal alive?
  (or animal? vegetable?))
(define-signal animal?
  (or mammal? reptile? bird?))
(define-signal animate?
  (or animal? robot?))

Here, you must give all the inputs of the signal as part of the signal definition. It is often useful to leave the inputs implicit and instead declare the outputs of a signal, just as one commonly prefers to define classes by listing their superclasses rather than by exhaustively listing all their subclasses. This can be done using accumulators, as in:

(define-signal alive? (accumulate or))
(define-signal animate? (accumulate or))

(define-signal animal? (accumulate or)
  (drives alive? animate))
(define-signal mammal? ...
  (drives animal?))

(define-signal robot? ...
  (drives animate?))

or, to add a little syntactic sugar:

(define-syntax define-class
  (syntax-rules ()
    ((define-class ?name (?superclasses ...))
     (define-signal ?name (accumulate or)
       (drives ?superclasses ...)))))

(define-class alive? ())
(defne-class animate? ())

(define-class animal? (alive? animate))
(define-class mammal? (animal?))

(define-class robot? (animate?))

which more closely matches the way we tend to think about implication rules and taxonomic definitions. For examples of fancier versions of this, see the rulesets package or the situations package.

Modal-inference package

In the following, a logic-expression is a signal that carries the true-value(s) of a proposition or a unary predicate. Unary predicates are represented as bit-vectors.

(know logic-expression): True when logic-expression's value is known.
(know-that logic-expression): True when logic-expression's value is known and its true.
(goal logic-expression): True when logic-expression is a goal.
(maintain-goal logic-expression): True when logic-expression is a maintanance goal.
(maintain logic-expression): Equivalent to logic-expression except that (goal (maintainx)) is defined to be (maintain-goal x).
(unsatisfied-goal logic-expression): True when logic-expression is a goal, but it's know to be false.
(satisfied-goal logic-expression): True when logic-expression is a goal and it's know to be true.
(know-goal logic-expression): True when determining logic-expression's value is a goal.

Goal reduction

Goal reduction allows you to specify that a given signal or signals should be activated when a given modality of a given signal is active.

(define-reduction (modality signal) serial): Declares goal reduction should be performed serially, left-to-right along signal's inputs. That is, (goal (and a b)) will first assert (goal a), then when a is satisfied, assert (goal b).
(define-reduction (modality signal) parallel): Declares goal reduction should be performed in parallel for all of signal's inputs. That is, (goal (and a b)) will simultaneously assert (goal a) and(goal b).
(define-reduction (modality signal) subgoal-signal): Declares that (modality signal) should be reduced to subgoal-signalI. That is, that (modality signal) should drive subgoal-signal.

Role-passing

Role-definitions package

The role-passing extensions implement circuit-semantics for a subset of modal logic in which quantification is limited to a finite domain consisting of linguistic roles. Roles are represented as bit-masks in which each role is reserved one position. This allows logical operations on sets of roles to be performed with single machine instructions.

Roles

The set of roles is determined in advance and is exported by the role-passing package. The current set of roles is: agent, patient, object, instrument, cause, origin, destination, trajectory, and trajector. This set will grow, although there are implementation reasons to want to limit it to 32 roles. Internally, roles are defined as an enumeration type; however, the type is not exposed in the API. Instead, programmers should use the following macros:

(role role-name): Macro. Returns the bit-mask representing the role.
(roleset role-name ...): Macro. Returns the bit-mask for all the roles.
(role-index role-name): Macro. Returns the bit-number corresponding to the role at compile time.
role-count: The total number of roles.
(name->role-index symbol): Procedure. Returns the role index corresponding to a role name represented as a symbol at run-time.
(name->roleset symbol): Procedure. Returns the bitmask of symbol at run-time.
(role-list->roleset list): Procedure. Returns the roleset corresponding to a list of role names represented as symbols.
(roleset->role-list roleset): Procedure. Returns a list of symbols corresponding to the roles in the roleset.

Pools and binding

Binding is the process of tracking the relationships between roles and objects in the world. To represent a sentence like "take the green ball", we have to be able to represent the fact that the patient of the sentence is the green ball. This is done initially by tagging (binding) the representation of green in the lexicon, and eventually a visual tracker tracking the green ball, with the role tag patient.

Binding contexts

The binding package contains support for context switching between different sets of bindings. We still need to figure out the right way to use these, but the hooks are there to do the context switching. Here's the current (limited) API:

current-context: The context number of the currently active context. You can change the scheduling algorithm used by redefining this signal. At present, it is defined to be the arg-max of context-priority.
context-priority: Vector of priorities of each context.
max-contexts: The size of the pool of available contexts. This is a normal Scheme variable, not a signal.
(make-shared-context-vector initial-value): Returns a shared vector of size max-contexts with initial value initial-value.
(make-shared-context-array length initial-value &optional (name)): Returns a max-contexts´length array with initial value initial-value.

See also the section on the context pool, below.

Pools

Pools implement representational modalities that can describe objects. They are typically either memories, in which case the items in the pool are some kind of register, or sensory systems, in which case the items are collections of functionally equivalent sensory processes that can be dynamically allocated to different tasks.

GRL interface

(make-pool name size-or-items): Creates a new pool with the specified name and the specified vector of items. If an integer is provided for size-or-items then there is no actual vector of items stored in the pool.
(pool-bound? pool): Returns the roleset of roles bound withing pool.
(pool-name pool): Returns the name of the pool (a symbol).
(pool-bindings pool): Returns the vector which holds the role bindings for the items in pool.
(pool-size pool): Returns the number of items in pool.
(pool-ref pool index): Returns the indexth item in pool.
bound?: The roleset of all roles bound in some pool.
(pool-lookup pool roleset default): Returns the item bound to roleset in pool or default is no item is bound to roleset. If no vector of items was specified when the pool was created, then the slot index to which the role is bound is returned.
(join-pools pool1 index1 pool2 index2 &optional (gate #t)): Simulates the effect of sharing specific binding registers between pool1 and pool2. In particular, any items in the two pools whose respective entries in index1 and index2 will automatically have their bindings or'ed together on each clock cycle.

The following plan macros are also available for establishing and clearing bindings:

(bind-item! pool item roleset): Binds item to roleset in pool in the current context.
(pool-unbind! pool roleset): Unbinds all items in pool from all roles in roleset.
(global-unbind! roleset): Unbinds all items in all pools from all roles in roleset.

Low-level Scheme interface

In addition, the following low-level Scheme functions can be called from within transducers:

(%make-pool name size items): Creates a new pool with the specified name, size and vector of items. If no vector of items is to be specified, it should be set to #f.
(pool-bound? pool): Returns the roleset of roles bound withing pool.
(pool-name pool): Returns the name of the pool (a symbol).
(pool-bindings pool): Returns the vector which holds the role bindings for the items in pool.
(pool-size pool): Returns the number of items in pool.
(pool-set-bindings pool): Returns the vector set-bindings for pool.
(pool-access-times pool): Returns the vector access times for the items in pool.
(pool-ref pool index): Returns the indexth item in pool.
(%pool-context-start pool context): Returns the position in the pool's binding vector of the beginning of the context'th context.
(pool-slot-free? pool index): Returns true if the index'th slot in pool is not bound in any context.
(pool-slot-free! pool index): Frees (unbinds in all contexts) the index'th slot in pool.
(%pool-lookup pool context roleset default): Returns the item bound to roleset in context context in pool or default is no item is bound to roleset. If no vector of items was specified when the pool was created, then the slot index to which the role is bound is returned.
(%pool-lookup->slot pool context roleset): Returns the slot index of the item bound to roleset in context context in pool.
(%pool-allocate->slot! pool context roleset): Allocates an item slot in pool to roleset in context and returns its slot index. If no free item is available, the least recently used item is chosen and all its previous role bindings are cleared in all contexts.
(%bind-item! pool context item roleset): Binds item to roleset in pool in context.
(%pool-unbind! pool context roleset): Unbinds in context all items in pool from all roles in roleset.
(%global-unbind! roleset): Unbinds all items in all pools from all roles in roleset.

Predicates and functions over pools

(pool-predicate pool vector): Vector must be a Boolean vector of length equal to the number of items in the pool. Returns a predicate (i.e. a roleset) containing the roles of the items whose respective entries in vector are true.
(pool-function pool vector default): Returns a vector of length role-count whose ith element is the respective values from vector of whichever item in pool is bound to the ith role. If no item is bound to that role, then the element is default.

Set operations

In addition to normal bindings (called here "role-bindings", which would otherwise be redundant), whole sets of items can be bound to roles. These bindings are stored separately and are used for iterating over items with a some property.

(reset-sets! pool roleset): Clears all set bindings within pool for roles in roleset.
(select-all! pool roleset): Set-binds all items in pool to roleset.

Built-in pools

There are a number of pools that are exported by the binding package.

The context pool

Allocation and deallocation of contexts can be performed using the context-pool.

context-pool: The pool of contexts. Its size is (by definition) max-contexts.
context-bound?: Roleset of roles that are bound to contexts.
(spawn role priority action &rest action-args): A plan macro that creates allocates a context, binds it to role in the current context, assigns it priority, and sets it to run action with the specified arguments.

Action pool

Certain specially declared actions can also be bound to roles. These actions can then be called indirectly by role, have the status sensed by role, and can be active in some contexts but not others.

Caveat: reflected (bindable) actions can only take up to three arguments. All arguments must be integers.

(define-reflected-action defined-action-args ...): Defines an primitive action (i.e. a behavior) that can be bound to roles.

Reflected signals

There is also support to reflect arbitrary signals. However, a separate pool is generally needed for each signal type.

reflected-proposition-pool: Pool of bindable propositions (Boolean-valued signals).
(bind-proposition! name-or-signal roleset): Binds roleset to name-or-signal. If name-or-signal is of type symbol, then it is assumed to be the name of the signal to be bound. Otherwise, it is assumed to be the signal itself.
proposition-bound?: Roleset of roles bound to propositions.