EZ-Xpert currently generates CLIPS files which are incompatable with JESS due to the
use of an (allowed-values ...) modifier and the use of (type SYMBOL) instead of (type
ATOM) within deftemplates. I simply remove the modifier and replace the type using a
simple script, and they seem to work just fine. Dr. Friedman-Hill's proposed changes
will be of great use, and would not appear to break any CLIPS code generated by this
particular utility.
BTW, I think that I've convinced the author of EZ-Xpert to support JESS directly in
the next official release :-)
Richard Long
Senior Consultant
Breakaway Solutions, Inc.
101 Southhall Lane, 4th Floor, Maitland, FL 32751
407.667.4705 - Office
407.667.4800 - Fax
http://www.breakaway.com
Get there first.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Peter Martinovic
Sent: Wednesday, February 23, 2000 11:04 AM
To: Jess Mailing List
Subject: Re: JESS: A modest proposal
hello,
i'd like just to point on the question of jess compatibility with the visual
kb modeling tools (i don't use any but i know that there are some)... i
think usually they are clips compatible..
peter
-----Original Message-----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, February 23, 2000 2:10 PM
Subject: JESS: A modest proposal
>Hi Folks,
>
>I've been thinking about future plans for Jess. One quite modest
>change with perhaps far-reaching results is the following: what if
>fact-ids didn't change when a fact was modified? Then you could
>have a way to reliably refer to one fact from another, building all
>sorts of interesting data structures. This is a frequently-requested
>feature.
>
>(shopping-cart (items 2 7 6 3 9))
>(item (type eggs)) ;; fact-2
>(item (type milk)) ;; fact-7
>... etc.
>
>In fact, if fact-id's didn't change, I can think of lots of internal
>optimizations that could make Jess even faster. One is that RU.FACT_ID
>values could contain a reference to the Fact object itself, saving
>many lookups. In fact, the separate representation of a fact-id as an
>int could go away entirely: an RU.FACT_ID could simply call
>getFactId() on the embedded Fact.
>
>Anyway, it turns out this is very easy to do. Only one routine in Jess
>actually cares if the fact-ids change, and it is easily modified to
>not care. This will, however, break some CLIPS code which depends on
>fact-ids having specific values. Such code has always struck me as
>nasty, anyway, but I'm not sure how much of it exists. Is it important
>to keep CLIPS compatibility here? (I think not - there is much to gain
>and little to lose.) Opinions, please!
>
>Some other fact-related changes: currently all deftemplates, ordered
>and unordered, inherit from a deftemplate __fact with no slots. This
>isn't very useful. It could be much more useful if it were changed a
>little. For instance, what if __fact had a slot (id) which contained
>the fact-id? Then you could eaily find a fact with a given ID.
>
>What if __fact had a slot (head) which contained the "head" or name of
>the fact. Then you could find all facts of a given type, with the type
>being runtime data.
>
>What if __fact were the parent of deftemplates __ordered, which was
>the parent of all ordered deftemplates, and the slot 'data' that all
>ordered deftemplates have were moved up to the parent? Then you could
>find any ordered fact containing a given datum, regardless of head.
>
>I think all of these would be more or less transparent to existing
>code, but the features would be available. Again, opinions and
>suggestions are invited.
>
>
>
>---------------------------------------------------------
>Ernest Friedman-Hill
>Distributed Systems Research Phone: (925) 294-2154
>Sandia National Labs FAX: (925) 294-2234
>Org. 8920, MS 9012 [EMAIL PROTECTED]
>PO Box 969 http://herzberg.ca.sandia.gov
>Livermore, CA 94550
>---------------------------------------------------------------------
>To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
>in the BODY of a message to [EMAIL PROTECTED], NOT to the
>list (use your own address!) List problems? Notify
[EMAIL PROTECTED]
>---------------------------------------------------------------------
>
>
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
