I think Orchard, Bob wrote:
>
> First the 'single' slot activation is a bit mis-leading to me. I would
> prefer to see it labelled 'any' slot activation since any slot that
> is modifed can cause an activation (actually a 'match' of the pattern and
> not necessarily an activation -- rules are activated).
It took me a minute to understand what you were saying here, and I
think that's because...
> Following along
> with Alan's suggestions then instead of
>
> (declare (activate PER-SLOT|PER-TEMPLATE))
>
> I'd prefer to see ...
>
> (declare (activate ANY-SLOT |PATTERN-SLOT))
>
... you reversed the order of the options relative to Alan's. PER-SLOT
means the same as your PATTERN-SLOT, and ANY-SLOT is equivalent to
PER-TEMPLATE. ANY-SLOT is the current (and future default) behavior.
> To go a bit further, I wonder if designating this in the
> deftemplate or defclass is the right palce to do it.
This was my first impulse just because in CLIPS some templates have
the ANY-SLOT behavior and other templates (instances, actually) have
the PATTERN-SLOT behavior. You can't pick and choose.
But actually, in my implmentation the behaviors are handled by the
rule compiler, and the difference doesn't affect the nature of the
template at all, so there's nothing to prevent some patterns of a
given template type from being compiled as ANY-SLOT and others as
PATTERN-SLOT. That means the global default could be changed, and you
could indeed change it on a per-rule or per-pattern basis.
As you note, the per-pattern syntax could be ugly. Maybe PATTERN-SLOT
patterns could be enclosed by square brackets instead of parentheses,
or something like that? We're not actually constrained by traditional
LISP syntax, and I'm already giving very serious consideration to
{}-delimited blocks of embedded Java(-like) code.
One thing that worries me a little about changing the global default
is that making the change will only affect how rules are compiled
subsequent to the change; it wouldn't go back and change previous
rules. This could potentially be confusing, although probably wouldn't
come up very often...
I wonder if ONLY giving you the ability to make this decision on a
pattern-by-pattern basis would be enough. I posit that it would
indeed, and would be easy to use with the square-bracket syntax.
---------------------------------------------------------
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]
--------------------------------------------------------------------
