KIF and packages

Tom Gruber <gruber@ksl.stanford.edu>
Full-Name: Tom Gruber
Sender: Tom Gruber <gruber@hpp-ss10-1.Stanford.EDU>
Date: Fri, 25 Jun 1993 12:48:47 PDT
From: Tom Gruber <gruber@ksl.stanford.edu>
Reply-To: gruber@ksl.stanford.edu
To: ontolingua@ksl.stanford.edu
Subject: KIF and packages 
Message-id: <CMM.0.88.741037727.gruber@hpp-ss10-1.Stanford.EDU>

An issue has come up in the specification KIF and the design
of Ontolingua for which we need your opinion. 

KIF's uses the _syntax_ of the standard Common Lisp parser for the mapping
>From linear KIF (byte streams) into structured KIF (sequences and words).
The KIF spec does not say that you have to use Lisp to read or print KIF
(there are C++ parsers for KIF and many of our agents that speak KIF are
written in C, C++, and Prolog).

The decision to use Common Lisp syntax helps clarify a lot of detail that
would otherwise have to be spelled out in the KIF document.  However, some
things are yet to be spelled out.  We have been making assumptions about
these underspecified issues and embodying them in the ontolingua code, so
that we have an operational definition to work from.

One of those issues has to do with parsing and printing: in particular, how
KIF's syntax interacts with the Common Lisp package system.  The CL parser
and printer are parameterized by several variables, the most important of
which are *package* and *readtable*.  The values for *readtable* (and
related flags *read-base* *print-case*, etc.) can be given standard
settings when reading and printing KIF from lisp programs.  Packages are
more subtle.

In the current design of Ontolingua, we define a KIF package and take care
to ensure that every symbol defined in the KIF spec is exported.  We also
insure that this package _imports_ all the symbols of Common-Lisp.  Users
need only put ontologies in a package that uses KIF, like ontolingua-user,
and the package prefixes are never seen.  (This is different from having
each ontology in a standalone package, because it allows the translator
code a way to recognize when a KIF symbol is used in a user ontology.)

This means that LISP:LIST and KIF:LIST are the same symbol (they are EQ).

The rational for this is that, by default, Lisp packages import from the
Lisp package and Lisp programs are read into packages that include these
symbols.  So if someone writes a Lisp program to generate or recognize KIF,
then that programmer may write things like 'LIST and 'SET in their code.
Under the current scheme, that programmer can get away with this sloppyness
because 'LIST in his or her _code_ package will likely be EQ to 'KIF:LIST.

It turns out that this is not always a good idea.  For example, if you
wanted to implement a CLOS-based frame system that uses KIF syntax, then
you may find yourself creating CLOS classes for symbols such as LISP:LIST,
LISP:CLASS, etc.  This can cause havoc in some implementations.
Furthermore, many implemented systems (e.g., Loom, Epikit) include built-in
support for many Lisp symbols such as the list and number operators.  So
when such a system is told a definition for one of these symbols, (e.g.,
when loading in a KIF-based ontology about lists or numbers), it can break
things.

So consider this simple proposal: KIF is read and printed in packages that
are disjoint from the built-in Common Lisp package, and package prefixes
are to be avoided in KIF expressions.

In Lisp programs that manipulate KIF expressions, there could be a package
called KIF that exports all the official KIF words (this set could be
operationalized by public-domain ontolingua source code).  The KIF package
would import _no_ symbols.  Then KIF:LIST is different from LISP:LIST (and
LOOM:LIST, EPIKIT:LIST, etc.).  Ontologies that include KIF symbols should
be set up to import the KIF package, but not the LISP package.  Printing
and reading of an ontology or any other set of KIF sentences should always
be done with *PACKAGE* bound to the package that imports from KIF.
(Ontolingua supports this convention by associating a theory with an I/O
package).  Then we can organize ontologies in Lisp files written in
packages, while keep packages out of the KIF string->sequence mapping.

For programs not using a Lisp reader or printer, this just means that
package prefixes are never seen.  We don't use Lisp packages to
partition the KIF namespace. 

We are considering making this change to Ontolingua. Since we've been
careful to always say KIF:LIST instead if LIST in code, this is a simple
change to the definition of the KIF package (it makes life easier, in
fact).  However, if users have written code that depends on our previous
decision about the KIF package importing from the LISP package, then this
may cause trouble.  Let us know by replying with your rationale to this
list.

thanks

tom