Binding Interlingua symbols

• Mail folder: Interlingua Mail
• Next message: James Rice: "Re: Binding Interlingua symbols"
• Previous message: James Rice: "Re: Importing Common Lisp into Interlingua"
• Reply: James Rice: "Re: Binding Interlingua symbols"

Message-id: <9010021602.AA09901@vaxa.isi.edu>
To: James Rice <Rice@sumex-aim.stanford.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>
Reply-To: macgregor@isi.edu
Subject: Binding Interlingua symbols
Date: 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.

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.

>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.

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.

Cheers, Bob