Greetings. I'd like to introduce this community to Project LISA, a
platform for the development of intelligent software applications in
Common Lisp. LISA is a production rule system implemented in CLOS, and
is heavily influenced by the Java Expert System Shell (JESS). At its
core is a reasoning engine based on an object-oriented implementation of
the Rete algorithm (Charles L. Forgy, Artificial Intelligence 19(1982),
17-37.)
LISA is an Open Source effort hosted at Sourceforge. Currently I
consider the software to be in "alpha" condition, but as of 1 March
2001, LISA can successfully run an adaptation of the "monkey and
bananas" AI planning problem, on three Linux-based Lisp implementations
(LispWorks, Allegro and CMUCL). Right now I'm cleaning the code base and
writing some preliminary documentation in preparation for an initial
release.
There's still a lot of work to be done, and the pace of development will
likely be driven by the needs of the Lisp community. Initial releases
will be an attempt to gain feedback on things like language syntax,
architecture, the Lisp constructs I chose, etc. At this stage
performance is not a priority, although LISA runs the MAB quite
acceptably.
In any event, if you're interested in this sort of thing please visit
the LISA project site at http://lisa.sourceforge.net. Also, feel free to
contact me directly with comments and questions. Thanks much.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications (defun real-language? (lang)
(········@computer.org) (eq lang 'LISP))
"The fact that ... we still
live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
"David E. Young" wrote:
> Greetings. I'd like to introduce this community to Project LISA, a
> platform for the development of intelligent software applications in
> Common Lisp...
Just after I posted this announcement I was gently tasked by a member of
the CLISP development team to see if LISA would run on that implementation.
After making a few minor changes (probably related to different
interpretations of the Standard), LISA now runs the MAB on the latest
version of CLISP as well. The web site has been updated to reflect that
fact.
Thanks to Sam Steingold for "prodding" me; half a day's work helped make
LISA a little bit better.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications (defun real-language? (lang)
(········@computer.org) (eq lang 'LISP))
"The fact that ... we still
live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
Erik Naggum wrote:
> * "David E. Young" <·······@nc.rr.com>
> > After making a few minor changes (probably related to different
> > interpretations of the Standard), LISA now runs the MAB on the latest
> > version of CLISP as well.
>
> Can you be convinced to list those differences? I think the collective
> experience with these porting differences should be collected and made
> available to the ANSI committee and probably the ALU, as well.
>
Yes, absolutely. Indeed, I would like, after LISA reaches production
quality, to write a summary of my experiences with the various Lisp
implementations (Standard discrepancies, mistakes I made, etc.).
I'll collect my thoughts on the LISA CLISP port and post something here this
week.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications (defun real-language? (lang)
(········@computer.org) (eq lang 'LISP))
"The fact that ... we still
live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
Erik Naggum wrote:
> * "David E. Young" <·······@nc.rr.com>
> > After making a few minor changes (probably related to different
> > interpretations of the Standard), LISA now runs the MAB on the latest
> > version of CLISP as well.
>
> Can you be convinced to list those differences? I think the collective
> experience with these porting differences should be collected and made
> available to the ANSI committee and probably the ALU, as well.
>
I'm posting here three discrepancies I encountered while porting LISA to
CLISP. These aren't necessarily problems with CLISP, and I don't want to
appear to be "picking on" that implementation; these are just my
experiences.
From the project NOTES file:
* 3.9.2001: LISA has her first alpha release. Just prior to this
event I was asked to get LISA working on CLISP; doing so exposed
some platform discrepancies that I am recording here.
1. The function CLOS:CLASS-DIRECT-SLOTS is internal in CLISP,
external in the others. This is actually looks like a MOP issue.
2. The method INITIALIZE-INSTANCE: CLISP seems to be much more
strict vis-a-vis keyword arguments than the other Lisps. Perhaps
CLISP might not be interpreting CLtL2 correctly here, or perhaps
the other Lisps are too lax; it isn't completely clear to me from
my reading. For example:
(defclass rocky ()
((name :initarg :name
:initform nil
:reader get-name)
(buddy :initform nil
:reader get-buddy)))
(defmethod initialize-instance :after ((self rocky) &key (buddy nil))
(setf (slot-value self 'buddy) buddy))
(defun make-rocky ()
(make-instance 'rocky :name 'rocky))
Evaluating MAKE-ROCKY in CLISP yields:
*** - EVAL/APPLY: keyword :NAME is illegal for #<COMPILED-CLOSURE
#:COMPILED-FORM-117-1>. The possible keywords are (:BUDDY)
No complaints from the others.
Adding &ALLOW-OTHER-KEYS to INITIALIZE-METHOD allows CLISP to run
without complaint, but of course disables keyword argument
checking.
3. CLISP's implementation of LOAD doesn't understand logical
pathnames. According to CLtL2 it should, but I haven't yet found
this stated in the Hyperspec.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications (defun real-language? (lang)
(········@computer.org) (eq lang 'LISP))
"The fact that ... we still
live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike
From: Tim Bradshaw
Subject: Re: Announcing: The LISA project
Date:
Message-ID: <nkjvgpdfun2.fsf@tfeb.org>
"David E. Young" <·······@nc.rr.com> writes:
> 2. The method INITIALIZE-INSTANCE: CLISP seems to be much more
> strict vis-a-vis keyword arguments than the other Lisps. Perhaps
> CLISP might not be interpreting CLtL2 correctly here, or perhaps
> the other Lisps are too lax; it isn't completely clear to me from
> my reading. For example:
>
> (defclass rocky ()
> ((name :initarg :name
> :initform nil
> :reader get-name)
> (buddy :initform nil
> :reader get-buddy)))
>
> (defmethod initialize-instance :after ((self rocky) &key (buddy nil))
> (setf (slot-value self 'buddy) buddy))
>
> (defun make-rocky ()
> (make-instance 'rocky :name 'rocky))
>
> Evaluating MAKE-ROCKY in CLISP yields:
>
> *** - EVAL/APPLY: keyword :NAME is illegal for #<COMPILED-CLOSURE
> #:COMPILED-FORM-117-1>. The possible keywords are (:BUDDY)
>
> No complaints from the others.
>
This is definitely a nonconformance.
--tim
David Young wrote:
> I'm posting here three discrepancies I encountered while porting LISA to
> CLISP.
Are you using the "PCL'd" up version of CLISP or the default
install. There are documented CLOS non-compliances with CLISP[1].
However, in section 4.3 description of how to remove clos and a
link to a pcl for clisp.
ftp://clisp.cons.org/pub/lisp/clisp/packages/pcl.sept92f.clisp.tar.gz
This may work better with LISA. However, YMMV.
Best Regards,
:)will
[1] clisp.sourceforge.net/impnotes.html
Will Deakin wrote:
> David Young wrote:
>
> > I'm posting here three discrepancies I encountered while porting LISA to
> > CLISP.
>
> Are you using the "PCL'd" up version of CLISP or the default
> install. There are documented CLOS non-compliances with CLISP[1].
>
Good point; my CLISP is the default installation.
>
> However, in section 4.3 description of how to remove clos and a
> link to a pcl for clisp.
> ftp://clisp.cons.org/pub/lisp/clisp/packages/pcl.sept92f.clisp.tar.gz
>
Thank's for the information.
Regards,
--
-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications (defun real-language? (lang)
(········@computer.org) (eq lang 'LISP))
"The fact that ... we still
live well cannot ease the pain of
feeling that we no longer live nobly."
-- John Updike