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@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@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@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@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@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet