*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.
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.
ruletypo2 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
>