Re: Importing Common Lisp into Interlingua

James Rice <Rice@sumex-aim.stanford.edu>
Full-Name: James Rice
Message-id: <2863819129-1510550@KSL-EXP-35>
Sender: RICE@ksl-exp-35.stanford.edu
Date: Mon, 1 Oct 90  18:18:49 PDT
From: James Rice <Rice@sumex-aim.stanford.edu>
To: macgregor@isi.edu
Cc: Tom Gruber <Gruber@sumex-aim.stanford.edu>,
        "Matthew L. Ginsberg" <ginsberg@sunburn.stanford.edu>,
        interlingua@vaxa.isi.edu, Daneel Pang <pang@sumex-aim.stanford.edu>
Subject: Re: Importing Common Lisp into Interlingua
In-reply-to: Msg of Mon, 01 Oct 90 16:59:40 PDT from Robert MacGregor <macgreg@vaxa.isi.edu>

>>  Jim Rice's message states:

>>  > It would be foolish to assume that KIF users would
>>  > not want CLOS and such-like ...

>>  I regard this as very much an issue of debate.  Mike
>>  G.  placed a section into a version of the KIF
>>  document importing all non-side-effecting Lisp
>>  functions.  I would prefer to see *no* Lisp functions
>>  whatever in the Interlingua.  Instead, I think there
>>  should be a formal way to enter Lisp from the
>>  Interlingua when users desire to invoke Lisp.  We
>>  might at the same time invent an escape into Prolog,
>>  or whatever other host languages people consider
>>  appropriate.

>>  If Matt's proposal is the only alternative to
>>  importing all of Common Lisp into the Interlingua,
>>  then I am suddenly very much in favor of adopting his
>>  proposal (I would image that I'm employing
>>  counterfactual reasoning here).

>>  Cheers, Bob

I suspect that we may be agreeing violently here.  I'm not
in favour of exporting LISP symbols from the KIF package.
You might recall that my proposal suggested that the KIF
package should use the CL package but that it should
export only a small number of symbols.

Thus:

(defpackage KIF (:use "COMMON-LISP"))

(find-symbol "LIST" 'kif)
LIST

but:

(defpackage my-kif-package (:use "KIF"))

(find-symbol "LIST" 'my-kif-package)
NIL

I believe that no correct program/KB should load stuff into
the KIF package, just as no correct Lisp program should
side-effect the LISP package.

What I am saying, therefore, is that in order for the user
to build a package that is likely to be useful to him he
will probably want to use both KIF and COMMON-LISP.  In
fact, it's sort or accademic to me whether the KIF package
itself uses CL or not, since no user would ever directly
write in to the KIF package.  I'm not wedded to it either
way.  It is important to me, however, that the KIF package
should not export the CL symbols.

If the symbol kif:<= is not to be eq to lisp:<= then this
needs to be stated hard, fast and soon.

Having said this, it is equally important to me that,
given that KIF by its very nature assumes the existence of
a CL implementation, reader and such, it would be very sad
if a user were to get package barfage in the event of doing
as trivial (and I believe reasonable) as the following:

(defpackage my-kif-package (:use "KIF" "COMMON-LISP"))

The point that I was trying to make is that we have the
opportunity to make life easy for ourselves here.  We
could also make it very hard.

For example, we could define a KIF symbol called ASSERT,
which would be defined to make an assertion in to the KB.
This is different behaviour from LISP:ASSERT and so either
we would not be able to have an operationalized version of
ASSERT in KIF (see my last message) or we would have to
make KIF:ASSERT different from LISP:ASSERT.  This just
makes life hard for people who want to do simple things
like the above package definition.  If we had just called
the foperator TELL instead (for example) then this problem
would not have arrisen.

Thus, I would propose that all KIF symbols that can
reasonably be operationalized (e.g.  DEFRELATION) be
orthogonal to the symbols in the CL package.  This will
prevent any of these sort of problems.  I have no problem
with saying the same for reasonable symbols in PROLOG,
though clearly, we're going to run into the ASSERT problem
right away there.

I don't know whether anyone thinks that it is a good idea
really to be able to type KIF sentences at a listener
anyway, but if you do (and there are a bunch of arguments
concerning convenience of compilation and such in favour
of it) then this is one way (presumably of many) to
address the problem.

There are a whole bunch of things that need to be cleaned
up to make a good job of KIF 2.0.  This is just one of
them.

KIF 2.0 seems (to me) to be trying to slide towards saying
that "to exchange knowledge easily we have to be able to
exchange programming constructs of a sort too."  That's OK
with me if that's the declared intent but we need to have
a much clearer definition of the semantics of the DEF
forms, for example, to be able to exchange "programs"
effectively.

To take an example from Epikit (yes, I know, it isn't KIF
2.0).  If you do a (define-concept foo..., then this wipes
out everything to do with foo.  Does Kif:DefObject do the
same thing?  If so, why?  If not, why not?  We need a much
better specification of the side-effects being performed
on the knowledge base itself by these forms.




Rice.