Sorry about mixing the order in Alan's example and mine...
this would have been confusing.
> -----Original Message-----
> 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 guess I was thinking that this was a runtime thing and not a
compile-time decision.
>
> 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.
>
I agree. This would be the simplest solution. With this you wouldn't
want to change any global default. This might not satisfy Alan's
concern about more than 2 possible ways to do things ... the KARMA
option.
Patterns with just a template name like (factA) would match when any
slot was changed but patterns like [factA] would never(?) match since
there is no slot to match and it requires some slot 'in the pattern'
to change before matching can occur.
Need to think a bit more about 'not' patterns.
Bob.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
