The rule engine is still trying to approximate logic, even if not completely in a mathematical sense. One property quantifiers have to obey is DeMorgan's laws, so "forall ... " should be logically equivalent to "not exists .. such that not...", which in Drools becomes for example :
forall Cloth( dry ) <-> not Cloth( ! dry ) if forall returned false on an empty set, the equivalence would no longer hold. Notice that there is a second negation inside the pattern. (btw, the "not" CE has the semantics of "not exists") This is actually the way it is implemented internally, and no, I don't think that it would be appropriate to change it. Davide On 01/08/2014 12:32 PM, Sonata wrote: > laune wrote >> On 08/01/2014, Davide Sottara < >> dsotty@ >> > wrote: >>> Indeed it is true by convention, see also >>> http://en.wikipedia.org/wiki/Universal_quantification >>> >>> The only other alternative is to deprecate quantifiers altogether ;) >>> >> Ah, *by convention*, yes. One should exercise some care with "vacuous >> truths", however. Uttering statements such as "All the little green >> men in my room are from Mars" may not brand you as a liar, but you >> could be called "batty". ;-) >> >> -W >> >>> Davide >>> > Guys, I am not sure whats the arguing point here. But from a programmer's > and a Drools engine user's perspective, I would find forall(void) to return > false more convenient. > > Say for example: > forall(Cloth(dried)) then collect() > Programmingwise, I dont want to execute collect() when the Cloth() > collection is empty and do extra null checkings. > Performancewise, I also dont want to call collect() when there is actually > nothing to perform. > In terms of semantics, I purposely want to check for isDried is true, it is > easy to realize from the LHS that I only want to collect clothes when all of > them are dried, rather than I want to collect also empty air. > > On the contrary, if I really want to do the RHS even though the LHS has > nothing, I would have written: > not( exists( Customer() ) ) then takeanap() > and I will not write > forall( Customer(status == "gone") ) then takeanap() > because the latter needs to do extra property visits and string comparisons > and it is so indirect to express what I really want. > > I really dont care what the mathematical definition is unless you tell me > Drools is a math. engine rather than a rule engine to express business > requirements. That, I should update myself and take a step back to look at > Drools again. Just my own opinion :P > > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/forall-is-satisfied-when-there-is-nothing-tp4027553p4027593.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users