Re: Binding Interlingua symbols
James Rice <Rice@sumex-aim.stanford.edu>
Full-Name: James Rice
Message-id: <2863894072-6131334@KSL-EXP-35>
Sender: RICE@ksl-exp-35.stanford.edu
Date: Tue, 2 Oct 90 15:07:52 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: Binding Interlingua symbols
In-reply-to: Msg of Tue, 02 Oct 90 09:02:54 PDT from Robert MacGregor <macgreg@vaxa.isi.edu>
--> >From Jim Rice:
--> > I believe that KIF should probably state something
--> > like one of the following:
--> >
--> > i) it is an error for any symbol in the KIF
--> > package to be either BOUND, FBOUND, or have any
--> > properties associated with it.
--> >
--> > or
--> >
--> > ii) It is an error for a user or program to BIND,
--> > FDEFINE or associate a property with a symbol in
--> > the KIF package. Some symbols in the KIF package
--> > have the following definitions/fdefinitions...
--> It is an error for an implementation of KIF to overwrite
--> the definition of a KIF symbol.
--> I would label (i) the CCODE approach and (ii) the
--> RCODE approach. If the interlingua is indeed a CCODE,
--> then the issue of executing it directly does not
--> arise, and hence (i) is the correct choice. I believe
--> this means that the Interlingua can use any of the CL
--> symbols without conflict, since it isn't
--> side-effecting them in any way. However, I think this
--> also means that its irrelevant whether or not an
--> Interlingua implementation imports CL or not. Hence,
--> while I think I agree with much of what Jim Rice said
--> in his last two messages, it seems to me that most of
--> it is irrelevant if we choose a CCODE approach. For
--> example, problems with ASSERT, <= (which ought to be
--> eliminated from the Interlingua), etc. evaporate.
I guess that I'm not connected with the bit of culture
that binds CCode and RCode but I believe that I can
interpret a meaning for them. That's fine. The trouble I
have here is what looks like the "The CCode strategy
obviates a whole bunch of problems => use the CCode
strategy" reasoning that seems to happen as a result of
the above statement.
I haven't been tracking this issue. Has it been discussed
much (I'm not on the Interlingua list). Although I don't
have much of an opinion either way on whether to take the
CCode or RCode approach I'd be reluctant to pick one
simply on the basis of ease of implementation without
understanding the issues better. For example, CL opted in
favour of full lexical scoping and lexical closures. This
clearly complicated things considerably but I suspect that
many would believe that this was a "good decision."
--> Again from Jim Rice:
--> > Having said this, it is equally important to me
--> > that, given that KIF by its very nature assumes the
--> > existence of a CL implementation ...
--> I think Jim is right that the Interlingua has assumed
--> a CL implementation. However, that was before the
--> CCODE/RCODE distinction arose. I suggest that the
--> Interlingua ought to be envisioned as relatively host
--> language independent. That means that we might
--> produce something that would also be relevant to
--> people coding in C++, Prolog, etc. This is easier if
--> we assume a formal escape to Lisp if we wish to use
--> Lisp symbols.
Although I would be delighted, putting my evangelical,
global-minded hat on, if the Interlingua was in some sense
host language independent, I don't think that this is
possible with the current state of affairs. It seems to
me that KIF is currently assuming the existence of a CL
reader (not counting the presense of the EVAL operator in
section 10.4).
Although the examples in KIF 2.0 generally are simple and,
I suppose could be lexed and parsed by a relatively simple
non CL program as they stand, it still seems that KIF
admits the lexical concept of SYMBOLS, even if it is
unclear whether other lexically deduced data types are
permitted, other than fixnums, which themselves are known
not to be portable.
As has been mentioned in previous messages, KIF 2.0 is
silent on the package issue but you can be dead sure that
users will want some mechanism to separate namespaces.
This is likely to be particularly important when we start
to merge separately developed KBs. Thus, unless KIF
develops its own formal specification for the partitioning
of namespaces, which the reader for a CL implementation of
KIF might choose to interpret as packages, we are pretty
well stuck with a CL reader and hence assuming the
presence of CL.
Maybe what is required is a specification for a sort of
"Inner KIF" and an "Outer KIF" such that inner KIF would
be super restrictive about readable things, i.e. no
package shifts, no macros, reader macros, bignums or non
portable data types, such as chars, #(...) and the like,
would make some declaration about the minimum value of
(what in CL would be) most-positive-fixnum so that a
reasonable range of integers can be reasoned about and
would disallow (it is an error for...) any Inner KIF KB
using EVAL. Outer KIF might be used as an interchange
format between known CL implementations of KIF.
I have the feeling that, in practice, users will want to
write their code in a reasonably application oriented
manner and thus will want to get away from pure KIF
syntax. Thus, I would expect KBs in general to look
something like the following (for a trivial example):
(defmacro deflink (name (from to) &body defined-by)
"Declares a link between From and To called Name."
(labels (($ize (x) (intern (concatenate 'string "$" (symbol-name x))
(symbol-package x)))
(subst-all (new old in)
(if new
(subst-all (rest new) (rest old)
(subst (first new) (first old) in))
in)))
`(kif:defprimrelation ,name (,($ize from) ,($ize to))
,@(subst-all (list ($ize from) ($ize to)) (list from to) defined-by))))
(deflink father-of (father child)
(male father)
(or (son-of child father)
(daughter-of child father)))
....
;;; Which might macroexpand into:
(KIF::DEFPRIMRELATION FATHER-OF ($FATHER $CHILD) (MALE $FATHER)
(OR (SON-OF $CHILD $FATHER) (DAUGHTER-OF $CHILD $FATHER)))
Thus, I would expect that in practice there might well be
a strong argument in favour of allowing LISP code of the
type above to be expressed in a KIF KB as well as just KIF
sentences. Clearly, this would reduce portability in the
most global sense but might increase portability in a
narrower sense by allowing people to axiomatize their own
KB tools, e.g. LOOM, in terms of KIF and not have to deal
with the porting issue of their KBs. Thus they could ship
their KB's in their prefered form, whilst also shipping
a small macro package preamble to do the translation.
I'm not wedded to either side, but I believe that we
should be absolutely clear about what we're buying into by
picking RCode or CCode and their respective
implementational implications.
--> >From Mike:
--> > I did not propose those lisp subroutines as a way of
--> > getting any procedural stuff into kif. They were
--> > chosen so that we could have standard names for
--> > functions like sin and cos.
--> I thought I remembered a version of the KIF document
--> that included car, cadr, caddr, etc. Possibly that
--> has been expunged from more recent versions. In any
--> case, those didn't sound like standard math functions
--> to me.
The version I have is full of CADDDDR and such (sections
10.4, 11 and 12).
--> Furthermore, if we assume a large library of CL math
--> functions, then we have again shut out anyone not
--> using CL. So I would recommend that if you want to
--> use all of these math functions, that you explicitly
--> use the CL lisp functions, and export that fact. If
--> you just use +, -, *, /, (which ought to be in the
--> Interlingua), then a non-Lisp host would have no
--> problem finding its analogues of these functions.
I'm not entirely sure that a non-lisp implementation will
be able to give the same semantics as we all assume all
the time for +, -, * and / with any ease. Mind you, I
suspect that once a decision has been made on the CCode
and RCode issue then one could resolve the declared
semantics of the permitted non-logic operators (in the
CCode case) fairly easily and in the RCode case there
would be no issue because we would have agreed on CL
semantics.
--> It might be good if we formally decided whether we're
--> building a CCODE or an RCODE, since that would finesse
--> half of the issues that have been arising.
I agree, though I would substitute the word "could" for
"would" above, since "would" rather implies that the CCode
approach will be selected by the decision process.
--> Cheers, Bob
Rice.