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