4:16 a.m.
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
4:59 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8 a.m.
+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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:09 a.m.
:)
Leonardo, the ";" is correct.
"We have adopted the RuleML's
POSL<http://ruleml.org/submission/ruleml-shortation.html>(Positional
Slotted Language) approach to mixing positional terms and OO
named arg arguments.... blah blah.
Just to explain positional arguments are ones where you don't need to
specify the field name, as the position maps to a known named field. i.e.
Person( name == "mark" ) can be rewritten as Person( "mark"; ). The ;
is
important so that we know when that everything before it is a positional
argument. Otherwise we might assume it was a boolean expression, which is
how it could be interpretted after the ; "
So the ";" acts to separate slotted\named parameters and positional.
With kind regards,
Mike
On 20 April 2011 14:00, Leonardo Gomes <leonardo.f.gomes(a)gmail.com> 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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:42 a.m.
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(a)gmail.com <mailto:michael.anstis@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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3:52 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:27 a.m.
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:50 a.m.
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(a)gmail.com
<mailto:michael.anstis@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(a)codehaus.org
<mailto:mproctor@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(a)gmail.com <mailto:michael.anstis@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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
4:25 a.m.
@ge0ffrey,
*you* know "looc" is a typo, but "loc" could equally be an unused
bound
variable and "looc" an unused output value.
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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:45 a.m.
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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)gmail.com
> <mailto:michael.anstis@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(a)codehaus.org
> <mailto:mproctor@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(a)gmail.com <mailto:michael.anstis@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(a)gmail.com <mailto:ge0ffrey.spam@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(a)lists.jboss.org
<mailto:rules-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rules-dev mailing list
> >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
11:23 a.m.
Wolfgang,
Jess/clips have never differentiated between binding and constraint. has
that been a major problem for Jess?
(cheese name ?cn )
(person likes ?cn )
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 )
In most common cases I think the separation is preferred, users do not
need to be concerned with the concepts of unification. 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.
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(a)gmail.com
<mailto:michael.anstis@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(a)codehaus.org
<mailto:mproctor@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(a)gmail.com <mailto:michael.anstis@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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:07 p.m.
On 21 April 2011 18:23, Mark Proctor <mproctor(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:04 p.m.
The aim of the positional syntax is to appeal to those that work this
way or prefer positional, such as prolog users.
I would stress that the positional stuff is purely optional. Those that
wish can completely ignore it as though it never existed without any
loss of functionality.
You can call queries and have unification, without ever using
positional, and thus you'll never see the ; separator. The ; is used
only when you use positional syntax, to differentiate it from a boolean
eval.
Ceylon has adopted this and also proposes ; as a separator between named
and positional constructors on java objects.
The other option we discussed was wrapping positional arguments in an
array symbol, to make it more obviously different.
predName( [pos1, pos2, pos3], name == xx )
Edson preferred the above, I preferred ; as too many parenthesis and
brackets is confusing. It also adds an undue readability burdon on those
wishing to work purely in positional, meaning they would probably be
discinclined to adopt drools which would defeat the goal of the proposal
- which is to encourage positional users. ; is not over bearing enough
to discourage people who favour positional, and named argument people
can continue as though it never existed.
So that explains the motive and the decisions on ;
There is the other issue that geoffrey has brought up which is related
to our decision to support a unification syntax in a manner that
Jess/Clips and Prolog do now. The following two unification approaches
are now possible:
Cheese( $cn : name )
Person( $name : name, $cn : likes) // $cn constraint is a unification.
---
Cheese( $cn ) // assuming cheese name was position 1
Person( $name, $cn)
Geoffrey wante a way to differentiate unification, whether an argument
is an input or an output. Any symbol added to the positional unification
argument would need to also be applicable to the named unfication
argument for consistency. <- and -> would just be over kill. We briefly
considered using : on positional arguments, but realised it created an
inconsitency with named which would still retain the issue of what is <-
and what is ->
i.e. while this would work for positional
Cheese( $cn : ) // shows that $cn is an output unification variable
Person( $name, $cn ) // $cn is an input variable and would error if
$cn does not exist.
But this wouldn't help named, which would need a further symbole to
differentiate. As mentioned earlier == is not applicable as it's not a
constraint filter, it is a unification variable and has different wider
reaching behaviour.
Cheese( $cn : name )
Person( $name : name, $cn : likes)
Over all I feel what we have proposed is a reasonable compromise on
readability and regularity.
Mark
On 21/04/2011 18:07, Wolfgang Laun wrote:
On 21 April 2011 18:23, Mark Proctor<mproctor(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:35 p.m.
New subject: Backwards chaining: the difference between input and output variables
http://www.cse.unsw.edu.au/~billw/cs9414/notes/prolog/intro.html
If Prolog finds a variable name that you only use once in a rule, it
assumes that it may be a spelling mistake, and issues a *Warning* about
a "singleton variable" when you load the code:
%/prolog -q -s mycode.pl/
Warning: .../mycode.pl:4:
Singleton variables: [Item]
http://www.cs.toronto.edu/~dianaz/2501/Manual/sec-B.html
*singleton [variable]*
Variable
<http://www.cs.toronto.edu/%7Edianaz/2501/Manual/sec-B.html#gloss:variable...
appearing only one time in a clause
<http://www.cs.toronto.edu/%7Edianaz/2501/Manual/sec-B.html#gloss:clause>;.
SWI-Prolog normally warns for this to avoid you making spelling
mistakes. If a variable appears on purpose only once in a clause,
write it as |_| (see anonymous
<http://www.cs.toronto.edu/%7Edianaz/2501/Manual/sec-B.html#gloss:anonymou>)
or make sure the first character is a |_|. See also the
style_check/1
<http://www.cs.toronto.edu/%7Edianaz/2501/Manual/sec-3.42.html#style_check...
option |singletons|
4999
days inactive
5000
days old
13 comments
5 participants
participants (5)
-
Geoffrey De Smet -
Leonardo Gomes -
Mark Proctor -
Michael Anstis -
Wolfgang Laun