<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Wolfgang,<br>
<br>
Jess/clips have never differentiated between binding and constraint.
has that been a major problem for Jess?<br>
(cheese name ?cn )<br>
(person likes ?cn )<br>
<br>
In previous DRL we did not allow unification like above. So you were
forced to separate binding and constraint:<br>
Cheese( cn : name )<br>
Person( likes == cn )<br>
<br>
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.<br>
<br>
Mark<br>
<br>
<br>
On 21/04/2011 07:27, Wolfgang Laun wrote:
<blockquote
cite="mid:BANLkTi=yJtifRNW51vQd3AB+qpbp8JRGtA@mail.gmail.com"
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
moz-do-not-send="true" href="mailto:michael.anstis@gmail.com">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
moz-do-not-send="true" href="mailto:mproctor@codehaus.org">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
moz-do-not-send="true" href="mailto:michael.anstis@gmail.com">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
moz-do-not-send="true" href="mailto:ge0ffrey.spam@gmail.com">ge0ffrey.spam@gmail.com</a>>
wrote:<br>
>>>><br>
>>>> Mark and I were discussing backwards chaining<br>
>>>> <a moz-do-not-send="true"
href="http://blog.athico.com/2011/04/backward-chaining-emerges-in-drools.html">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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> rules-dev mailing list<br>
>>> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>