@ge0ffrey,<br><br>*you* know "looc" is a typo, but "loc" could equally be an unused bound variable and "looc" an unused output value.<br><br>I find it difficult to see there is sufficient "context" to give a suitable error message - other than perhaps warning of unused bindings.<br>
<br>@wolfgang,<br><br>Your proposition works for slotted parameters; whereas the ";" allowed for positional parameters too.<br><br>AFAIK the BC changes bring two discrete features: BC and positional parameters.<br>
<br>@all<br><br>I've expressed my "simpleton" view on how, as a user, I would best understand its operation.<br><br>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.<br>
<br>Being just a "feeling" I am happy to watch this discussion evolve and learn from others' experience.<br><br>With kind regards,<br><br>Mike<br><br><div class="gmail_quote">On 21 April 2011 07:50, Geoffrey De Smet <span dir="ltr"><<a href="mailto:ge0ffrey.spam@gmail.com" target="_blank">ge0ffrey.spam@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"><div>
<blockquote type="cite">and instead have the tooling inject what
ever is necessary as a visulation.</blockquote>
</div><blockquote type="cite">> Most questions we have to the user
mailing list involve people writing DRL not using tooling.</blockquote>
IntelliJ users and NetBeans users don't have any (up-to-date) DRL
tooling.<br>
Some Eclipse users I know don't install extra plugins such as the
drools plugin out of fear of Eclipse instability.<br>
The new Eclipse plugin wont do that visualization yet either?<br>
<br>
<br>
I like Laun's and Manstis and mine proposal,<br>
as long as there's something in the syntax that makes it clear
whether that food is<br>
- an input variable => constrains the rule, potentially
decreasing the number of activations<br>
- an output variable => frees the rule, potentially increasing
the number of activations<br>
<br>
And a typo shouldn't change the behavior from one to the other, it
should give a compilation error.<br>
<div><code>rule</code>
<code>typo2<br>
</code><code>when</code></div>
<div><code> </code><code>Here( loc : location)<br>
</code></div>
<div><code> </code><code>?</code><code>editableThings</code><code>(food, </code><code>looc</code><code>;)</code><code> // looc is a
typo of loc</code></div>
<div><div><code>then</code><br>
System.out.println("Food " + f + " at location " + loc);<br>
// Output:<br>
// Food crackers at location kitchen<br>
// Food apple at location kitchen<br></div>
// Food chocolate at location kitchen // BUG: that food is in
the living room!<br>
// Food chips at location kitchen // BUG: that food is in the
living room!</div>
<div><code>end<br>
<br>
<br>
</code></div>
<br>
<br>
Op 21-04-11 08:27, Wolfgang Laun schreef:
<div><div></div><div><blockquote type="cite">Designing syntax well is not easy. With extensions,
one should strive for as much<br>
conformity with the existing language, while trying to follow
general principles.<br>
<br>
One might have discussed (for instance) the use of field names for
referencing<br>
the query relations, taken from their parameter definition. And
then one could write,<br>
as usual:<br>
<br>
?editableThings(food: thing, location == loc )<br>
<br>
or<br>
<br>
?editableThings(food: thing, loc: location )<br>
<br>
And the in/out is clear to all who know a little legacy DRL.<br>
<br>
And the ugly semicolon evaporates.<br>
<br>
And the maintainability/readability disadvantage of "positional"
is gone.<br>
<br>
Cheers<br>
-W<br>
<br>
<br>
On 20 April 2011 22:52, Michael Anstis <<a href="mailto:michael.anstis@gmail.com" target="_blank">michael.anstis@gmail.com</a>>
wrote:<br>
><br>
> Simple yes, but consistent too should be a factor.<br>
><br>
> Most questions we have to the user mailing list involve
people writing DRL not using tooling.<br>
><br>
> So DRL, IMO, has to be seen as the "tool" to author rules.
Drop the proposed colon altogether or make it's use consistent.<br>
><br>
> On 20 April 2011 17:42, Mark Proctor <<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>>
wrote:<br>
>><br>
>> 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.<br>
>><br>
>> Mark<br>
>> On 20/04/2011 14:00, Leonardo Gomes wrote:<br>
>><br>
>> +1 for Michael's suggestion.<br>
>><br>
>> It's a bit more verbose, but makes things clear.<br>
>><br>
>> The semicolon here:<br>
>> ?editableThings(food : ?, loc;)<br>
>><br>
>> Is a typo, right? You actually meant:<br>
>><br>
>> ?editableThings(food : ?, loc);<br>
>><br>
>> - Leo.<br>
>><br>
>><br>
>><br>
>> On Wed, Apr 20, 2011 at 11:59 AM, Michael Anstis <<a href="mailto:michael.anstis@gmail.com" target="_blank">michael.anstis@gmail.com</a>>
wrote:<br>
>>><br>
>>> Hmmmmm....<br>
>>><br>
>>> 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:-<br>
>>><br>
>>> rule outputinput<br>
>>> when<br>
>>> Here( loc : location)<br>
>>> ?editableThings(food : ?, loc;)<br>
>>> then<br>
>>> System.out.println("Food " + food + " at location
" + loc);<br>
>>> // Output:<br>
>>> // Food crackers at location kitchen<br>
>>> // Food apple at location kitchen<br>
>>> end<br>
>>><br>
>>> rule outputOutput<br>
>>> when<br>
>>> ?editableThings(food : ?, loc : ?;)<br>
>>> then<br>
>>> System.out.println("Food " + food + " at location
" + loc);<br>
>>> // Output:<br>
>>> // Food crackers at location kitchen<br>
>>> // Food apple at location kitchen<br>
>>> // Food chocolate at location living room<br>
>>> // Food chips at location living room<br>
>>> end<br>
>>><br>
>>> rule typo<br>
>>> when<br>
>>> Here( looc : location)<br>
>>> ?editableThings(food : ?, loc : ?;)<br>
>>> then<br>
>>> System.out.println("Food " + food + " at location
" + loc);<br>
>>> // Output:<br>
>>> // Food crackers at location kitchen<br>
>>> // Food apple at location kitchen<br>
>>> // Food chocolate at location living room<br>
>>> // Food chips at location living room<br>
>>> // looc is just an unused bound variable<br>
>>> end<br>
>>><br>
>>> On 20 April 2011 10:16, Geoffrey De Smet <<a href="mailto:ge0ffrey.spam@gmail.com" target="_blank">ge0ffrey.spam@gmail.com</a>>
wrote:<br>
>>>><br>
>>>> Mark and I were discussing backwards chaining<br>
>>>> <a href="http://blog.athico.com/2011/04/backward-chaining-emerges-in-drools.html" target="_blank">http://blog.athico.com/2011/04/backward-chaining-emerges-in-drools.html</a><br>
>>>> on IRC and we 'd like your opinion on a design
issue.<br>
>>>><br>
>>>> The example<br>
>>>> ========<br>
>>>><br>
>>>> Let's say you have this data:<br>
>>>> Location("crackers", "kitchen")<br>
>>>> Location("apple", "kitchen")<br>
>>>> Location("chocolate", "living room")<br>
>>>> Location("chips", "living room")<br>
>>>><br>
>>>> Let's say you have this code:<br>
>>>><br>
>>>> query editableThings( String thing, String
location )<br>
>>>> Location(thing, location)<br>
>>>> end<br>
>>>> And then these 3 rules:<br>
>>>><br>
>>>> rule outputinput<br>
>>>> when<br>
>>>> Here( loc : location)<br>
>>>> ?editableThings(food, loc;)<br>
>>>> then<br>
>>>> System.out.println("Food " + f + " at
location " + loc);<br>
>>>> // Output:<br>
>>>> // Food crackers at location kitchen<br>
>>>> // Food apple at location kitchen<br>
>>>> end<br>
>>>><br>
>>>> rule outputOutput<br>
>>>> when<br>
>>>> ?editableThings(food, loc;)<br>
>>>> then<br>
>>>> System.out.println("Food " + f + " at
location " + loc);<br>
>>>> // Output:<br>
>>>> // Food crackers at location kitchen<br>
>>>> // Food apple at location kitchen<br>
>>>> // Food chocolate at location living room<br>
>>>> // Food chips at location living room<br>
>>>> end<br>
>>>><br>
>>>> rule typo<br>
>>>> when<br>
>>>> Here( looc : location)<br>
>>>> ?editableThings(food, loc;)<br>
>>>> then<br>
>>>> System.out.println("Food " + f + " at
location " + loc);<br>
>>>> // Output:<br>
>>>> // Food crackers at location kitchen<br>
>>>> // Food apple at location kitchen<br>
>>>> // Food chocolate at location living room<br>
>>>> // Food chips at location living room<br>
>>>> end<br>
>>>><br>
>>>> The discussion<br>
>>>> =========<br>
>>>><br>
>>>> Both rules have the same statement:<br>
>>>> ?editableThings(food, loc;)<br>
>>>><br>
>>>> In the outputInput rule, "loc" is an input
variable.<br>
>>>> In the outputOutput rule, "loc" is an output
variable.<br>
>>>><br>
>>>> I am wondering if we don't need a visual
demarcation that a variable is an output variable,<br>
>>>> to make it stand out of an input variable?<br>
>>>><br>
>>>> Proposition 1: Suffix output variables with ":"<br>
>>>><br>
>>>> rule outputinput<br>
>>>> when<br>
>>>> Here( loc : location)<br>
>>>> ?editableThings(food:, loc;)<br>
>>>> then ... end<br>
>>>><br>
>>>> rule outputOutput<br>
>>>> when<br>
>>>> ?editableThings(food:, loc:;)<br>
>>>> then ... end<br>
>>>> rule typo<br>
>>>> when<br>
>>>> Here( looc : location)<br>
>>>> ?editableThings(food:, loc;) // compiler
error because input variable loc is not declared<br>
>>>> then ... end<br>
>>>><br>
>>>> --<br>
>>>> With kind regards,<br>
>>>> Geoffrey De Smet<br>
>>>> _______________________________________________<br>
>>>> rules-dev mailing list<br>
>>>> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> rules-dev mailing list<br>
>>> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-dev mailing list<br>
>> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-dev mailing list<br>
>> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div></div><pre cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>