The LISA Project

Recent News

20 October, 2002: LISA 2.0's third alpha release is now available. See the release notes for new features.

17 October, 2002: LISA 2.0's second alpha release is now available. See the release notes for details.

1 October, 2002: The first 2.0 alpha release, 2.0a1, is now available from the project site. See the release notes for a brief description.

30 September, 2002: LISA 2.0 successfully ran the MAB today. This version contains a ground-up reimplementation of Rete, plus an improved parsing engine. The new algorithm appears to be about twice as fast as the 1.x version, but I haven't confirmed this. An alpha release for 2.0 will be released soon.

17 August, 2002: A significant change in the project direction. LISA's most recent bug report, involving a subtle problem in the Rete network, has sparked some serious thinking on my part. When I first started the project I 1) read Forgy's paper for an introduction; 2) closely studied two existing Rete implementations (Jess, CLIPS); then 3) borrowed aspects from both and put together a CLOS implementation. The plan was to use this initial version as a test bed of sorts until I thoroughly understood the algorithm, but LISA acquired some early users and I concentrated on feature work instead. Now I find myself with a bug in an area of LISA that falls into the "why was this particular design path chosen", and I can't answer that question and can't immediately solve the problem.

So, I have decided it's time to overhaul the project. I'm going to do several things:

1. Branch the development tree and create a LISA 2.0 path.
   
2. Reorganize the code base such that it will support multiple matching algorithms (much work here).
   
3. Return to Forgy's original paper and write, from scratch, a "reference implementation" in CLOS that represents the essence of Rete without some of the later optimizations used by Jess/CLIPS (join node sharing, etc.). I'll maintain the fast join node memories, but that's it for optimization in the RI.
   
4. By this time I should completely grok Rete and be able to enhance and fix LISA's current algorithm.

Once these things have been done LISA will be in a position to support other algorithms; experimental versions of Rete, TREAT (maybe), whatever. They will simply "plug in" to the engine framework and "just run".

Now, what is the impact here? I intend to suspend all work on 1.x; there simply is no time to do the overhaul plus add new features to that trunk.
This probably means no more bug fixes to 1.x unless someone is really desperate. Since that's not likely I don't anticipate a problem here.

6 August, 2002: Release 1.3.1 is out. This is a bugfix release that addresses a significant problem with LISA's support for class hierarchy reasoning. There are also a few enhancements and modifications. See the ChangeLog in the distribution for details. For anonymous CVS users, the release tag for 1.3.1 is Release_1-3-1.

22 July, 2002: LISA release 1.3 is now available. See the project ChangeLog for details; there are numerous significant changes and enhancements.

1 June, 2002: There's a release 1.3 on the horizon, incorporating major overhauls in several areas. Among the changes,

1. Release snapshots: I've decided to begin releasing interim snapshots that will be available via anonymous CVS through the LISA project page. I know of at least one individual that acquires LISA this way via the release tags I've applied to the code base. This is a clean way to offer early access to upcoming releases without cluttering up the download page with tons of transient files.
   
   
2. Internal fact representation: I've merged the CLOS and template representations of facts into a single model. Gone are SHADOW-FACTS and separate methods of handling DEFTEMPLATE and DEFIMPORT facts. A unified view is now in place. The immediate ramifications are 1) queries now function with both types of facts, as LISA creates a class representing each template and instantiates it for each fact; 2) the ASSERT macro can be used with DEFIMPORTS, in addition to the traditional ASSERT-INSTANCE. Point (2) was a surprising side-effect; I hadn't anticipated this.
   
   
3. DEFIMPORT changes: DEFIMPORT has been completely rewritten and simplified. The new specification requires only a class name and an optional keyword argument that indicates whether or not the class hierarchy should be considered during pattern matching. By default, LISA will make available all slots and all classes in the hierarchy. This change will break existing code, but I believe the simplified interface is much improved and makes better sense.
   
   
4. Documentation: The code base is being completely documented. I've only done a handful of files but work is proceeding. A tedious but necessary task, and it is reacquainting me with aspects of LISA that have been stable for over a year.
   
   
5. MP support: I want to remove MP synchronization code from LISA, and place the burden of multi-thread access on the developer (for now). My current approach to MP is not the way it should be done. This doesn't mean LISA won't be re-entrant; multiple threads may be in LISA as long as each thread is operating on a different inference engine instance. However, if an application has several threads that operate concurrently within the same engine then the application must manage synchronization. No more than one thread may be running within the same engine at any one time. To assist developers here, the macro WITH-INFERENCE-ENGINE will remain, and I'll also export a special variable, representing the "active inference engine", that may be let-bound. In the future, I might employ the concept of multiple working memories; i.e. each thread would own its working memory and thus multiple threads could be running concurrently within the same engine. This will need exploration.

18 May, 2002: I've decided to change the way facts are represented internally. Currently, LISA makes a distinction between facts defined by deftemplate and facts represented as CLOS instances, primarily for a bit of efficiency when CLOS reasoning isn't required. However, this makes things a bit mushy internally and prohibits the use of queries on template facts. As of release 1.3, all facts will be backed by a corresponding CLOS instance. A little bit of performance will be sacrificed for a cleaner implementation and fully functional queries. Along the way I'm also probably going to simplify the syntax of defimport. Details in an upcoming update.

16 April, 2002: Release 1.2 is out, and I've taken a step back to survey the project. LISA has been in development now for about eighteen months. In the beginning, I had this (probably unrealistic) notion that LISA would grow to be some type of Grand Unified Agent Development Platform for Lisp. Lately however, I've begun to see LISA as something more modest and practical; a relatively light, clean inference engine for small to medium scale Lisp applications that would benefit from production rule technology. The fact that I'm the sole developer probably has something to do with this philosophical shift (if indeed it is a shift); there's only so much time to go around. Rather than move on to new feature work for version 1.3, I've decided to pause development and concentrate on fully documenting the source code. If someone needs some capability in LISA and just can't wait I'll consider revising my plans, but for now documentation and cleanup is my principal immediate goal.