[rules-dev] Backwards chaining: the difference between input and output variables
Wolfgang Laun
wolfgang.laun at gmail.com
Thu Apr 21 13:07:43 EDT 2011
On 21 April 2011 18:23, Mark Proctor <mproctor at codehaus.org> wrote:
> Wolfgang,
>
> Jess/clips have never differentiated between binding and constraint. has
> that been a major problem for Jess?
> (cheese name ?cn )
> (person likes ?cn )
It was, apparently, not applauded throughout, and I can understand
that. Not a "major" problem, but also small inconveniences irk. The
1st occurrence defines, then it's usage. The parser distinguishes
easily, and users get used to it.
BUT, overall, the syntax here is not at all convenient and that's why
the much more plausible form using "{likes == ?cn}", etc., has been
introduced where you would use Java-style relations for constraints,
leaving "{name ?cn}" for binding.
>
> In previous DRL we did not allow unification like above. So you were forced
> to separate binding and constraint:
> Cheese( cn : name )
> Person( likes == cn )
>
Perhaps Jess followed Drools here :) - it's clearer, and preferable.
> In most common cases I think the separation is preferred, users do not need
> to be concerned with the concepts of unification.
Yes, yes, and yes.
> What I have done is to
> allow unification in the manner than Jess and Clips does, this is important
> for prolog itself because the second pattern is not a filter. So == does not
> make sense, it is a unification.
You are not trying to tell me here that tje creation of an activation
by selection of a fact by equality of one or more of its fields is
not a "unification"? Or that the distinction "identity" vs. "equality"
suddenly does not matter? It's not really "unification" in the sense
that object must be IDENTICAL - it's still based on equality,
whichever way it is defined. I see no reason not to use "==". But use
another operator (e.g., -:- ) if you think that this is an issue.
In Prolog-style terms you don't need an operator because you don't use
anything except equality. BTW: What would happen if you permit the
usual relational operators in those BC-terms?
But mainly it's the positional-ness I don't like.
Wolfgang
>
> Mark
>
>
> On 21/04/2011 07:27, Wolfgang Laun wrote:
>
> Designing syntax well is not easy. With extensions, one should strive for as
> much
> conformity with the existing language, while trying to follow general
> principles.
>
> One might have discussed (for instance) the use of field names for
> referencing
> the query relations, taken from their parameter definition. And then one
> could write,
> as usual:
>
> ?editableThings(food: thing, location == loc )
>
> or
>
> ?editableThings(food: thing, loc: location )
>
> And the in/out is clear to all who know a little legacy DRL.
>
> And the ugly semicolon evaporates.
>
> And the maintainability/readability disadvantage of "positional" is gone.
>
> Cheers
> -W
>
>
> On 20 April 2011 22:52, Michael Anstis <michael.anstis at gmail.com> wrote:
>>
>> Simple yes, but consistent too should be a factor.
>>
>> Most questions we have to the user mailing list involve people writing DRL
>> not using tooling.
>>
>> So DRL, IMO, has to be seen as the "tool" to author rules. Drop the
>> proposed colon altogether or make it's use consistent.
>>
>> On 20 April 2011 17:42, Mark Proctor <mproctor at codehaus.org> wrote:
>>>
>>> My personally opinion is to keep the language simple and instead have the
>>> tooling inject what ever is necessary as a visulation. Be it different
>>> colouring, hover over or graphic symbol. It keeps the language simple and
>>> actually achieve the desired result better.
>>>
>>> Mark
>>> On 20/04/2011 14:00, Leonardo Gomes wrote:
>>>
>>> +1 for Michael's suggestion.
>>>
>>> It's a bit more verbose, but makes things clear.
>>>
>>> The semicolon here:
>>> ?editableThings(food : ?, loc;)
>>>
>>> Is a typo, right? You actually meant:
>>>
>>> ?editableThings(food : ?, loc);
>>>
>>> - Leo.
>>>
>>>
>>>
>>> On Wed, Apr 20, 2011 at 11:59 AM, Michael Anstis
>>> <michael.anstis at gmail.com> wrote:
>>>>
>>>> Hmmmmm....
>>>>
>>>> Personally, I don't like the use of ":" i isolation as it's what we
>>>> currently use to bind variables and I feel "cheese:" as an output definition
>>>> could just make people question whether they've missed something. Perhaps
>>>> "cheese : ?" would be a viable alternative. This would be in keeping with
>>>> (a) current variable declaration, (b) the use of "?" to identify a call to a
>>>> query. Geoffrey's examples would then become:-
>>>>
>>>> rule outputinput
>>>> when
>>>> Here( loc : location)
>>>> ?editableThings(food : ?, loc;)
>>>> then
>>>> System.out.println("Food " + food + " at location " + loc);
>>>> // Output:
>>>> // Food crackers at location kitchen
>>>> // Food apple at location kitchen
>>>> end
>>>>
>>>> rule outputOutput
>>>> when
>>>> ?editableThings(food : ?, loc : ?;)
>>>> then
>>>> System.out.println("Food " + food + " at location " + loc);
>>>> // Output:
>>>> // Food crackers at location kitchen
>>>> // Food apple at location kitchen
>>>> // Food chocolate at location living room
>>>> // Food chips at location living room
>>>> end
>>>>
>>>> rule typo
>>>> when
>>>> Here( looc : location)
>>>> ?editableThings(food : ?, loc : ?;)
>>>> then
>>>> System.out.println("Food " + food + " at location " + loc);
>>>> // Output:
>>>> // Food crackers at location kitchen
>>>> // Food apple at location kitchen
>>>> // Food chocolate at location living room
>>>> // Food chips at location living room
>>>> // looc is just an unused bound variable
>>>> end
>>>>
>>>> On 20 April 2011 10:16, Geoffrey De Smet <ge0ffrey.spam at gmail.com>
>>>> wrote:
>>>>>
>>>>> Mark and I were discussing backwards chaining
>>>>>
>>>>> http://blog.athico.com/2011/04/backward-chaining-emerges-in-drools.html
>>>>> on IRC and we 'd like your opinion on a design issue.
>>>>>
>>>>> The example
>>>>> ========
>>>>>
>>>>> Let's say you have this data:
>>>>> Location("crackers", "kitchen")
>>>>> Location("apple", "kitchen")
>>>>> Location("chocolate", "living room")
>>>>> Location("chips", "living room")
>>>>>
>>>>> Let's say you have this code:
>>>>>
>>>>> query editableThings( String thing, String location )
>>>>> Location(thing, location)
>>>>> end
>>>>> And then these 3 rules:
>>>>>
>>>>> rule outputinput
>>>>> when
>>>>> Here( loc : location)
>>>>> ?editableThings(food, loc;)
>>>>> then
>>>>> System.out.println("Food " + f + " at location " + loc);
>>>>> // Output:
>>>>> // Food crackers at location kitchen
>>>>> // Food apple at location kitchen
>>>>> end
>>>>>
>>>>> rule outputOutput
>>>>> when
>>>>> ?editableThings(food, loc;)
>>>>> then
>>>>> System.out.println("Food " + f + " at location " + loc);
>>>>> // Output:
>>>>> // Food crackers at location kitchen
>>>>> // Food apple at location kitchen
>>>>> // Food chocolate at location living room
>>>>> // Food chips at location living room
>>>>> end
>>>>>
>>>>> rule typo
>>>>> when
>>>>> Here( looc : location)
>>>>> ?editableThings(food, loc;)
>>>>> then
>>>>> System.out.println("Food " + f + " at location " + loc);
>>>>> // Output:
>>>>> // Food crackers at location kitchen
>>>>> // Food apple at location kitchen
>>>>> // Food chocolate at location living room
>>>>> // Food chips at location living room
>>>>> end
>>>>>
>>>>> The discussion
>>>>> =========
>>>>>
>>>>> Both rules have the same statement:
>>>>> ?editableThings(food, loc;)
>>>>>
>>>>> In the outputInput rule, "loc" is an input variable.
>>>>> In the outputOutput rule, "loc" is an output variable.
>>>>>
>>>>> I am wondering if we don't need a visual demarcation that a variable is
>>>>> an output variable,
>>>>> to make it stand out of an input variable?
>>>>>
>>>>> Proposition 1: Suffix output variables with ":"
>>>>>
>>>>> rule outputinput
>>>>> when
>>>>> Here( loc : location)
>>>>> ?editableThings(food:, loc;)
>>>>> then ... end
>>>>>
>>>>> rule outputOutput
>>>>> when
>>>>> ?editableThings(food:, loc:;)
>>>>> then ... end
>>>>> rule typo
>>>>> when
>>>>> Here( looc : location)
>>>>> ?editableThings(food:, loc;) // compiler error because input
>>>>> variable loc is not declared
>>>>> then ... end
>>>>>
>>>>> --
>>>>> With kind regards,
>>>>> Geoffrey De Smet
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> rules-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
More information about the rules-dev
mailing list