[rules-dev] Backwards chaining: the difference between input and output variables
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Thu Apr 21 07:45:40 EDT 2011
Op 21-04-11 11:25, Michael Anstis schreef:
> @ge0ffrey,
>
> *you* know "looc" is a typo, but "loc" could equally be an unused
> bound variable and "looc" an unused output value.
This is not the case if output values require to be suffixed by ":", ":
?" or ": location" (= propositions geoffrey, manstis or laune).
The point is, currently (= proposition mark), they are not required to
be suffixed,
so "looc" is indeed seen as an unused output value (instead of input value)
and doesn't raise a compilation error.
>
> I find it difficult to see there is sufficient "context" to give a
> suitable error message - other than perhaps warning of unused bindings.
>
> @wolfgang,
>
> Your proposition works for slotted parameters; whereas the ";" allowed
> for positional parameters too.
>
> AFAIK the BC changes bring two discrete features: BC and positional
> parameters.
>
> @all
>
> I've expressed my "simpleton" view on how, as a user, I would best
> understand its operation.
>
> It isn't based upon science or a wealth of experience with a multitude
> of other programming languages; just a "feeling" of what I consider right.
>
> Being just a "feeling" I am happy to watch this discussion evolve and
> learn from others' experience.
>
> With kind regards,
>
> Mike
>
> On 21 April 2011 07:50, Geoffrey De Smet <ge0ffrey.spam at gmail.com
> <mailto:ge0ffrey.spam at gmail.com>> wrote:
>
>> and instead have the tooling inject what ever is necessary as a
>> visulation.
>> > Most questions we have to the user mailing list involve people
>> writing DRL not using tooling.
> IntelliJ users and NetBeans users don't have any (up-to-date) DRL
> tooling.
> Some Eclipse users I know don't install extra plugins such as the
> drools plugin out of fear of Eclipse instability.
> The new Eclipse plugin wont do that visualization yet either?
>
>
> I like Laun's and Manstis and mine proposal,
> as long as there's something in the syntax that makes it clear
> whether that food is
> - an input variable => constrains the rule, potentially decreasing
> the number of activations
> - an output variable => frees the rule, potentially increasing the
> number of activations
>
> And a typo shouldn't change the behavior from one to the other, it
> should give a compilation error.
> |rule| |typo2
> ||when|
> |||Here( loc : location)
> |
> |||?||editableThings||(food, ||looc||;)||// looc is a typo of 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 kitchen // BUG: that food is in
> the living room!
> // Food chips at location kitchen // BUG: that food is in the
> living room!
> |end
>
>
> |
>
>
> Op 21-04-11 08:27, Wolfgang Laun schreef:
>> 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
>> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto:rules-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> rules-dev mailing list
>> >>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> rules-dev mailing list
>> >> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> rules-dev mailing list
>> >> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > rules-dev mailing list
>> > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto: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
--
With kind regards,
Geoffrey De Smet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110421/77fe5489/attachment-0001.html
More information about the rules-dev
mailing list