Re: KIF and packages
Tom Gruber <Gruber@sumex-aim.stanford.edu>
Message-id: <2863377226-903706@KSL-Mac-69>
Date: Wed, 26 Sep 90 15:33:46 PDT
From: Tom Gruber <Gruber@sumex-aim.stanford.edu>
To: "Matthew L. Ginsberg" <ginsberg@sunburn.stanford.edu>,
interlingua@vaxa.isi.edu
Cc: James Rice <Rice@sumex-aim.stanford.edu>
Subject: Re: KIF and packages
In-reply-to: Msg of Wed, 26 Sep 90 13:22:51 -0700 from "Matthew L. Ginsberg" <ginsberg@sunburn.stanford.edu>
> That certainly will need to be addressed, but it is unfortunately
> not that simple. The reason is that most systems have already got
> something called "true" and when you do the use-package, you get
> a name conflict. (I know this from my experience trying to port a
> system that uses something called "true".)
> My own suggestion would be to make the symbols exported as Tom
> suggests, but *not* expect the user to do a use-package. Simply
> put the interlingua document itself in the KIF package and let
> the recipient sort it out as appropriate to his system.
Of course. There should be no REQUIREMENT or ASSUMPTION that the user
does a use-package. In practice I recommend against it when trying to
port somebody else's code, and it is especially unfriendly when an
application does it "for the user". The fact that there is a
significant overlap of symbols in KIF and Lisp, and that many users
will, in fact, try to import KIF symbols into a package that also uses
common-lisp, motivates the design decision to have the KIF package use
the common-lisp. If the user of a system that defines
"mypackage::true" wants to read or print KIF KBs, she may want to say
(defpackage "MYPACKAGE"
(:use "KIF" "COMMON-LISP")
(:shadow KIF:TRUE)
...)
or she may want to read and print her KBs with KIF:TRUE and KIF:=>.
tom