Ernest,

   as usual it looks as though you are ahead of the curve. I was holding off on 6.x 
for a while (indeed, to
be honest
I haven't event downloaded it yet ) -- but that will soon change.

On the issue of the 'general list' it would seem to me that augmenting Jess with such 
a type might not be a
bad idea - it would allow one to build defrules, facts and funcalls on the fly (or 
take them apart). This
can be done implicitly for facts (via str- functions  and assertString), so why not 
defrules or
deffunctions ?? So:

(assert '(foo a b c)) would be the same as (assert (foo a b c))
(defrule '(name  (cond1) (cond2) => (action1)(action2))) would do what you would 
expect etc.

Probably multifield fuctions could be applied to the inside of one of these guys .. 
and so on.

It wouldn't impact the speed that comes from Rete compilation since once the list was 
rule or factified
there is no change in the semantics of the system (well perhaps there is -- I don't 
know what the lifecycle
of such a constructed rule would be).

Anyway -- idle ruminations.

Tnx
Alanl



friedman_hill ernest j wrote:

> Hi Alan,
>
> You're not missing anything obvious; your analysis of the problem is
> good, and you've figured out for yourself that there's something funny
> about how Jess's pseudo-LISP is implemented. In a real LISP, all data
> structures are made out of cons cells, and a list we think of as a
> function call (like (bind ?x foo)) is no different than one that looks
> like a fact (like (initial-fact)). In Jess, though, everything is not
> built from cons cells. There are instead Fact and Funcall and Defrule
> objects. This is nice and object-oriented, but the problem with this
> approach is that the decision to turn a bunch of characters into a
> Fact or Funcall or whatever is made when the text is parsed. The
> parser therefore has to be built to recognize the language syntax of
> rules and facts etc., unlike the LISP reader which is far simpler and
> more generic. In any case, this sort of explains why there's no
> quote operator: there's no such thing as a generic, uninterpreted list
> in Jess.
>
> In any event, Jess 6.0a1 actually has a new function in it that does
> more or less what you want. it's called (call-on-engine) and you can
> use it as shown below. In this snippet, I create a second Rete
> instance from within the main one and store it in variable ?e; I then
> assert various facts into it, reset it, call (facts) on it, etc. I
> make a local (facts) call too so you can see that the facts are in the
> "other" engine, not the one connected to the command line
> directly. Let me know what you think.
>
> bash-2.03# java jess.Main
>
> Jess, the Java Expert System Shell
> Copyright (C) 1998 E.J. Friedman Hill and the Sandia Corporation
> Jess Version 6.0a1 4/25/2000
>
> Jess> (bind ?e (new jess.Rete))
> <External-Address:jess.Rete>
> Jess> (call-on-engine ?e (assert (foo bar)))
> <Fact-0>
> Jess> (call-on-engine ?e (facts))
> f-0   (foo bar)
> For a total of 1 facts.
> Jess> (facts)
> For a total of 0 facts.
> Jess> (deftemplate boo (slot bar))
> TRUE
> Jess> (call-on-engine ?e (assert (boo (bar 3))))
> <Fact-1>
> Jess> (call-on-engine ?e (facts))
> f-0   (foo bar)
> f-1   (boo (bar 3))
> For a total of 2 facts.
> Jess> (call-on-engine ?e (reset))
> TRUE
> Jess> (call-on-engine ?e (facts))
> f-0   (initial-fact)
> For a total of 1 facts.
> Jess>
>
> I think Alan Littleford wrote:
> > I'm doing some experiments with mutiple engines within the same process and I hit 
>the following
> > issue. I'd like to construct a function that lets me assert a fact in a different 
>engine - i.e. I'd
> > like to do something like
> >
> > (defrule ..
> >     (some-fact ?parameter)
> >     (other-engine-instance ?rete)
> >     =>
> >     (assert-across-engines ?rete (a-new-fact ?parameter))
> > ..)
> >
> > The way I see it is I can turn my fact into a string:
> >
> >     (assert-across-engines ?rete (str-cat "(a-new-fact " ?parameter ")"))
> >
> > and use assertString inside my function. sadly this fails if any of the slots are 
>Java objects.  Or I
> > can create a new Fact
> > in the new context then munge over the slots, parameter at a time, which at least 
>lets me pass Java
> > object references. Both techniques are, of coure, slow and messy.
> >
> > What I want to write is  what I wrote - the exact analogue to  (assert (a-new-fact 
>?parameter)). It
> > seems to me that something along the lines of the lisp ' would be useful (I think 
>I have this correct
> > - it has been an ____age____ since I wrote any lisp) i.e. don't evaluate this, 
>just treat it as a
> > form:  (assert-across-engines ?rete '(a-new-fact ?parameter)).
> >
> > Or am I missing something _very_obvious here .. ??
> >
> > Tnx
> > Alanl
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
> > ---------------------------------------------------------------------
> >
>
> ---------------------------------------------------------
> 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]
---------------------------------------------------------------------

Reply via email to