Hi all,
Wow, a guy goes on vacation for the summer, and a lot of good stuff got
generated on the list in the mean time...I'm still absorbing it, but would
like to get my two cents worth in.
Let me first of all put in my vote for this feature: I believe it will have
very positive implications for design, performance and validation
particularly for larger systems. I have a bunch of rambling design notes on
specifically why, in my humble experience, this is so, but maybe I'll leave
that for some other posting.
As for a name, I like Alan's argument for non-Boolean option here, and
"PER-SLOT" works for me, but hey, anything will do.
Bob's idea for a global setting sounds like a good idea. I for one would use
that as a default: saving a whole lot of repeated syntax elsewhere, and
associating the behavior with the engine instance, not the data structures.
I also agree with Bob that there may be cases where one rule would like to
treat a template (pattern) as PER-SLOT and another rule would like to treat
the same template on a PER-TEMPLATE basis (in other words, pattern matching
behavior is a function of a rule, not necessarily of a class).
In particular note cases where a common set of templates (classes) is used
in separate rule sets (this template re-use occurs commonly in my
architecture - in somewhat the same way as a database schema is used for
many environments and applications; ditto interfaces.). This is an argument
for associating the matching behavior with the rules or engine instance, and
not the data structures upon which they act.
Just to throw another option into the mix, what about enabling or disabling
this behavior with a pair of CE's? For example (building on Bob's syntax)
(set-default-pattern-match PATTERN-SLOT-CHANGES)
((defrule r
(ALL (foo (bar ?x)))
=>)
In this example an engine has been set to perform only per-slot activations,
BUT the "ALL" CE overrides that default for the foo template in this rule to
match on all slot modifications of that template. In contrast:
(set-default-pattern-match ANY-SLOT-CHANGES)
(defrule r
(ONLY (foo (bar ?x)))
=>
)
This is the opposite case, where default behavior is as the current Jess
engine, and "ONLY" forces matches only on slots explicitly named in the
enclosed pattern.
I'm not necessarily advocating this Ernest, just adding to the pile of
options: I have no clue regarding implementation ramifications, and
implementation is a factor.
2 cents worth,
Jack
(PS I am now posting from Infosolve rather than Transcanada - those are one
and the same)
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Jess Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 27, 2003 9:28 PM
Subject: JESS: "Single-slot activations"
> Hi Folks,
>
> So I've got a partial implementation of this thing we've been calling
> "single-slot activations"; this is the Jess mode in which if a fact is
> matched by a rule, and some slot in that fact which is not explicitly
> mentioned in the rule's patterns is modified, the rule's activation
> state is unchanged.
>
> This is going to be a property of certain deftemplates --
> i.e., you can say
>
> (deftemplate foo (declare (xyzzy TRUE)) (slot x) (slot y))
>
> to get a template that will behave this way.
>
> My dilemma: I don't have a catchy name for this. I actually have been
> coding it up using the nonce word "xyzzy", just as shown in the
> example. What should this be called instead? "single-slot-activation"
> is kind of ungainly. I want to change this, finish the implementation,
> and have a "technology preview release" to let people play with it and
> get some feedback. Suggestions welcome.
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Distributed Systems Research Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> PO Box 969, MS 9012 [EMAIL PROTECTED]
> Livermore, CA 94550 http://herzberg.ca.sandia.gov
>
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------
