Binding Interlingua symbolsRobert MacGregor <firstname.lastname@example.org>
To: James Rice <Rice@sumex-aim.stanford.edu>
Cc: Tom Gruber <Gruber@sumex-aim.stanford.edu>,
"Matthew L. Ginsberg" <email@example.com>,
firstname.lastname@example.org, Daneel Pang <email@example.com>
Subject: Binding Interlingua symbols
Date: Tue, 02 Oct 90 09:02:54 PDT
From: Robert MacGregor <firstname.lastname@example.org>
>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.
> 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
> 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.
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.
> 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.
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.
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.