ML and Logistica
tony@ontek.com (Tony Sarris)
Reply-To: cg@cs.umn.edu
Date: Thu, 11 Nov 93 10:23:28 PST
From: tony@ontek.com (Tony Sarris)
Message-id: <9311111823.AA06859@ontek.com>
To: cg@cs.umn.edu
Subject: ML and Logistica
Cc: brown@CS.ukans.edu, interlingua@isi.edu, tony@ontek.com
The recent discussions about the use of FOL to ensure various kinds of
closure and to support [deductive] inference touched on ML as a language in
which to express various logics (as functions). I wanted to make the
subscribers of this network aware of another, emerging language similar
to ML but with additional capabilities. It may be useful when attempting
to represent complex domains such as those that are the subject of
enterprise information integration projects. The language is Logistica, as
developed by Dr. Frank Brown of the University of Kansas and Artificial
Intelligence Research (AIR), Inc.
Logistica is a computer language which can be used as a tool for building
inference systems. It is not based on a particular kind of logic, but allows
different kinds of logics to be defined and used as the basis for reasoning
systems. The value of this is that the language is very flexible and may be
applied to many different situations.
More specifically, Logistica is a lexically-scoped functional programming
language used for implementing deductive reasoning processes. Although
at the simplest level Logistica looks like the Scheme dialect of LISP, it
differs in that symbols may have any number of definitions instead of
always just one as in Scheme. The reason for this difference is that there
are usually many axiomatic properties of any symbol and thus to represent
them in a useful modular fashion a separate definition is needed to
represent each property. For example, one definition of conjunction might
represent the associative law of conjunction, and another definition might
represent the idempotent law of conjunction. In the simple case where no
symbol is defined more than once, Logistica is essentially the same as
Scheme. For this reason, Logistica can be viewed as one possible
explication of [Pat Hayes'] thesis that deduction and computation are
similar activities.
Allowing multiple definitions of symbols is reminiscent of PROLOG's use
of several clauses beginning with a particular predicate to axiomatize
that predicate. The difference is that Logistica allows multiple
definitions of all its symbols, including predicates, functions, and logical
connectives. The consequence of this rather slight conceptual change is
quite significant, in that expressions may have multiple values. Control
facilities similar to the cut operation of PROLOG are included for dealing
with multiple values. Because Logistica enables the specification of
arbitrary deductive systems (by representing the properties of symbols as
'backtrackable rewrite rules' which are associated to the symbols
themselves), it is independent of any specific logic and it provides instead
the basic tools for deduction.
In an execution environment, the capabilities of Logistica are intended to
support such things as multiple [pattern] matches on operation definitions
and multiple input states. A given input to a pattern-directed interpreter
may possibly match: none; exactly one; or many operation definitions.
Also, a given input operation may have: no arguments; exactly one set of
arguments (one input state); or many sets of arguments (many input
states). The power of a pattern-directed invocation mechanism depends on
how it handles the possible operation matches and their application to the
possible number of input states.
Of the existing pattern-based languages such as ML and PROLOG, Logistica
is the only one that can handle all of the possible cases of operation
matches and input states. In ML, for instance, even if there are several
operation definitions which match the input pattern, only the first match
will be returned. This means that ML can only execute one of possibly
many definitions for a given operation. PROLOG does return matches of
multiple operation definitions, but whether one or many operations are
returned, they are applied to only one input state. In the case where there
are many operation definition matches as well as multiple input states,
Logistica invokes the Cartesian cross-product of "operation definitions X
input states".
Next-generation database management systems implementing the
ANSI/ISO Three-Schema Architecture will require this capability because
there may be many possible target code solutions to any one user query,
and deciding which one is best for the purpose at-hand requires having
them all available at the same time for comparison. Associated condition
mechanisms will also require this capability because there may be more
than one possible action, or condition handler, to be invoked during a fault
in a three-schema database transaction. For example, you might have to do
both a DB2 DBMS image rollback and an IMS DBMS checkpoint/restart.
So aside from having languages such as ML and Logistica to support
theorem proving and inference in a general context, there are also
practical purposes for such languages in information technology
applications.
Dr. Brown is currently finishing documetation of his work on Logistica.
That documentation should be available from him or the Air Force shortly.
His work on the non-monotonic Modal Logic Z has been discussed and
referenced previously on this network. I would suggest that anyone
interested in finding out more about Logistica contact him on the internet
at "brown@CS.ukans.edu" or at the following address:
Artificial Intelligence Research, Inc.
2512 W. 6th Street, Suite D
Lawrence, KS 66049
voice: 913/832-1444
FROM: Tony Sarris, Ontek Corporation
tony@ontek.com