[rules-users] How to track constraint truth [was: Non short circuit ANDing]

[Wolfgang Laun]

Hello Davide,

a few comments, see inline.

On 04/02/2013, Davide Sottara <dsotty at gmail.com> wrote:
>
> I am still convinced that there should be better ways for the engine to
> provide argumentation facilities to the users.

See my final aside.

>
> The usecase here can be divided in two parts:
> - evaluate a chain of constraints, tracing which one(s) are satisfied and
> which ones are not
> - evaluate the overall formula, deciding whether an overall consequence
> should be fired or not.

Extension to the second part: There may be more than one overall
consequence, perhaps alternatives, perhaps in parallel or both.

>
> Wolfgang's suggestion, as usual, is correct: the constraints have to be
> broken apart. The alpha network
> evaluates them in a chain and does not notify the results of the
> evaluations. However, the proposed
> solution (extending a base rule) has a couple of problems
> - it relies heavily on (self) joins

Not necessarily - the secondary conditions could be written using
eval(). Also, pattern binding could be made to recognize a previous
binding. And, re the
argument for better efficiency below, efficiency isn't my foremost
worry when the  goal is to provide a sound way of solving a user's
problem.

> - it only handles the positive cases, e.g. color == "red", so that either a
> second rule (color != "red")
>   has to be written, or later one will have to look for the absence of the
> "success" fact derived from that
>   constraint.

But below you introduce Fulfillment and Violation facts and wonder
about the way to clinch the entire procedure. The Collector fact I use
provides all the answers, and it's just a single fact, not one for
each constraint.

>
> So, I'll follow up on my previous suggestion with this proposal:
>
[snip]
> At the moment, these facts have to be managed explicitly, but it would be
> great if the engine could
> provide more declarative ways to handle these use cases.
> I.e., something like the following rule allows a great deal of
> customization, but the "default" behaviour -
> dos insert Fulfillments, elses insert Violations - should probably be
> provided by the engine using some keyword ...
>
> rule "car"
> when
>   $car: Car( abs == true )
>   	if ( colour == "red" )
> 		do[red]
> 		else do[notRed]	// vs break[notRed]
>   Success( $car; )
> then[red]
>   System.out.println( ">>> Car is red " + $car );
>   insert( new Fulfillment( $car, "red" ); )
> then[notRed]
>   System.out.println( ">>> Car is NOT red " + $car );
>   insert( new Violation( $car, "red" ); )
> then
>   System.out.println( "The best Car is in " + $car );
> end
>

Mentally extending this by adding price, HP and ABS, I begin to yearn
for a generator that takes all the plodding work off my hands... Well,
I needed that for churning out the extensions, so I can't claim to be
better here :-)

I say: let users gain experience with a procedure that doesn't require
any built-ins and learn what would be a really helpful extension to
the engine, and *then* decide what to add to the engine.

As an aside: It's commendable to look for more and more additional
features, but remember the fate of the Vasa. ;-)

Cheers
Wolfgang