[rules-dev] RFC: declaration syntax

[Edson Tirelli]

   Thanks for the feedback Michael, and you are right, it will replace the
previous way of dealing with windows, but we will still support the old way
for backward compatibility.

   The idea is to have this working in the engine for Beta1, so I will let
you know as soon as the parser is done in the next couple days for you to
implement in guvnor as your schedule allow it.

   Thanks,
    Edson

2011/7/26 Michael Anstis <michael.anstis at gmail.com>

> Personally, I don't see a problem with option 1.
>
> For consistency (with entry-points) the named windows and usage thereof
> should, IMO, be defined thus:-
> *
> *
> **declare window X
>     @type( tumbling )
>     @keep( last 10 )
>     StockTick( symbol == "RHT" ) from entry-point Y
> end
>
> rule Z
> when
>     StockTick() from window x
> then
>     ...
> end
>
> I assume the window declaration supersedes "over window:length" and "over
> window:time", since the semantics seem to be defined in the declaration.
>
> Please let me know when this is closer to reality as Guvnor will need to
> support this.
>
> Cheers,
>
> Mike
>
> On 26 July 2011 20:28, Edson Tirelli <ed.tirelli at gmail.com> wrote:
>
>>
>>    All,
>>
>> BACKGROUND:
>>    As Drools moves forward, we need to be able to declare several new
>> structures, as well as make existing structures more robust for compile time
>> analysis, error reporting and tooling support. For instance, as it is today,
>> entry points are implicit declared by simply using them, i.e., if someone
>> writes a pattern:
>>
>> X() from entry-point Y
>>
>>    The engine will create entry-point Y implicitly. This is easy to use,
>> but this makes it impossible for the engine to detect typos and report
>> during compilation time. So, the idea is that we will allow the user to
>> declare all the entry points he wants to use in his application and we will
>> have a configuration option to enforce or not that list of declared entry
>> points. If the configuration is set to enforce and the engine finds a rule
>> that is using an entry point that is not part of the list, the engine can
>> raise a compile time error point out the user's mistake. E.g., using pseudo
>> code:
>>
>> declare entry-point X, Y
>> declare entry-point Z
>>
>>    Drools also needs a way to declare named windows for re-use on multiple
>> rules. For instance, using pseudo code:
>>
>> declare window X
>>     @type( tumbling )
>>     @keep( last 10 )
>>     StockTick( symbol == "RHT" ) from entry-point Y
>> end
>>
>>   And in the rule:
>>
>> rule Z
>> when
>>     StockTick() from window:named X
>> then
>>     ...
>> end
>>
>> QUESTION:
>>    As we can see above, we will need several new constructs in order to
>> support features in our roadmap. We have the choice of making them all top
>> level constructs, making the error recovery in the parser a lot more
>> complicated, or we can re-use our declare construct to define these new
>> structures as I presented in the pseudo-code above. Any pros/cons you can
>> see in such approach?
>>
>> OPTION 1 (more verbose, but simpler and more stable):
>> <epDeclaration> ::= declare entry-point <epName> [, <epName]*
>> <windowDeclaration> ::= declare window <windowName>
>> <restOfTheWindowDeclaration> end
>> <typeDeclaration> ::= declare [type] <typeName> <restOfTheTypeDeclaration>
>> end
>>
>> OPTION 2 (makes error recovery harder, but it is less verbose):
>> <epDeclaration> ::= entry-point <epName> [, <epName]*
>> <windowDeclaration> ::= window <windowName> <restOfTheWindowDeclaration>
>> end
>> <typeDeclaration> ::= declare <typeName> <restOfTheTypeDeclaration> end
>>
>> OPTION 3:
>> <epDeclaration> ::= someOtherKeyword entry-point <epName> [, <epName]*
>> <windowDeclaration> ::= someOtherKeyword window <windowName>
>> <restOfTheWindowDeclaration> end
>> <typeDeclaration> ::= declare [type] <typeName> <restOfTheTypeDeclaration>
>> end
>>
>>
>>    Edson
>>
>> --
>>   Edson Tirelli
>>   JBoss Drools Core Development
>>   JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110726/589b3219/attachment.html