Upcoming LISA release 1.3

"David E. Young" <[email protected]> Sat, 1 Jun 2002 11:58:53 -0400
Newsgroups gmane.lisp.lisa.general
Message-ID <002d01c20985$3bb0fb70$542bfea9@tinian>
Greetings. Lots of news, many changes.

1. 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 release
without cluttering up the download page with tons of transient files.

2. LISA has received a major overhaul in these areas:

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

b. DEFIMPORT changes: DEFIMPORT has been completely rewritten and
simplified. The new specification is

  (defimport classname &key (use-inheritancep t))

By default, LISA makes available all slots and all classes in the hierarchy.
If USE-INHERITANCEP is NIL, only the immediate slots are available and the
hierarchy is not considered during pattern matching. This change will break
existing code, but I believe the simplified interface is much improved and
makes better sense.

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

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

That's it. Lots going on. Major thanks to those of you who have contributed
suggestions and code (Paul Werkowski, Art Nuzzo) to help make LISA better.

Regards,
--
------------------------------------------
David E. Young
[email protected]
http://lisa.sourceforge.net

"Those who expect to reap the blessings of liberty
 must undergo the fatigues of supporting it."
  -- Thomas Paine

"But all the world understands my language."
  -- Franz Joseph Haydn (1732-1809)



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm