Rule grammar incomplete

[pieterbos]

Currently I'm implementing rules parsing. So far i've implemented what is in the grammar. Then I noticed the rules grammar is incomplete. At least missing is:

• variable declarations
• functions
• queries

Also I cannot find an existing testset for the rules, and no open source rule parsing library. They look very useful for several things (score calculation, conditional questions, custom validations, etc...) and we certainly want to support them, including variables and queries. But the lack of open source libraries supporting this, and the lack of use in the CKM makes me wonder - is this actually being used?

[borutf]

Thomas is keen on having it (it was added just recently to ADL2).
However my gut feeling is saying / yet another / functional language should be probably out of ADL scope, at least for now.

When you have a hammer everything looks like a nail, however I'm not sure we are ready for one-size-fits-all sort of model driven functional language. There probably must be a reason why we use R, rule lang, Java, SQL, ...

If we go that way we'll need to elaborate;

• Do we want to add a new functional language on top of existing options?
• How are we going to support libraries & reference calls?
• How this new functional language relates to GDL?

And above all -> how to get support from development community

I think it would be probably better to think of something like "handles".
My 5c.

[wolandscat]

There are certainly existing candidates for plugging in in some way, e.g. Xpath / Xquery is a surprisingly good predicate logic language; Javascript is pretty good as well. R is also clean although I have no experience with it. However, you can't literally plug them in because they can't reference archetype paths.

Various strategies seem possible if we want to write executable rules.

Strategy A
We choose one language as a model, and make an archetype version of that syntax that replaces variables with archetype paths (or maybe annotates variables with archetype paths). At runtime, we parse the rules in this language into a computational structure (i.e. an AST of some kind) and execute it in some container to get answers.

Strategy B
We just use a real language like JavaScript or Xpath, and use the normal way of declaring and referencing variables, plus we define mappings from those variable to archetype paths. Then at runtime, an interpreter converts the logic to an AST structure that is post-processed with the variable/path mappings to make it evaluatable.

There are probably other variants.

If we assume that the rules that will be written in archetypes and templates are relatively simple, i.e. really complex stuff will probably be in separate guidelines, then one of the above strategies is probably doable without much problem.

[ghost]

Sorry, I am very busy with all kind of things, and have no time to follow
discussions. But I am experienced in working with Antlr4. 5, so I might do
some easy jobs, for example, writing Java testfiles to test the
grammar-rules, or at least, a part of them.

If this is convenient, please, someone coordinates this, and tell me what
to do. I am very happy that you arrange a good grammar, and I will be happy
to do something back.

Best regards
Bert
Op 27 okt. 2015 18:22 schreef "Thomas Beale" [email protected]:

There are certainly existing candidates for plugging in in some way, e.g.
Xpath / Xquery is a surprisingly good predicate logic language; Javascript
is pretty good as well. R is also clean although I have no experience with
it. However, you can't literally plug them in because they can't reference
archetype paths.

Various strategies seem possible if we want to write executable rules.

Strategy A
We choose one language as a model, and make an archetype version of that
syntax that replaces variables with archetype paths (or maybe annotates
variables with archetype paths). At runtime, we parse the rules in this
language into a computational structure (i.e. an AST of some kind) and
execute it in some container to get answers.

Strategy B
We just use a real language like JavaScript or Xpath, and use the normal
way of declaring and referencing variables, plus we define mappings from
those variable to archetype paths. Then at runtime, an interpreter converts
the logic to an AST structure that is post-processed with the variable/path
mappings to make it evaluatable.

There are probably other variants.

If we assume that the rules that will be written in archetypes and
templates are relatively simple, i.e. really complex stuff will probably be
in separate guidelines, then one of the above strategies is probably doable
without much problem.

—
Reply to this email directly or view it on GitHub
#16 (comment).

[pieterbos]

Do I understand correctly that the rules grammar is part of ADL, but people generally use something else?

I asked about the rules grammar because I would like to do things the standard way if there is one. Also because I want to develop something that evaluates some kind of rules and release it. I could easily use the rules grammar with a few predefined mechanisms, like:

/somepath = expression -> set a computed value
boolean_expression implies exists /path -> show something conditionally
boolean_expression implies not exists /path -> hide/modify existence
boolean_expression implies /somepath = expression -> set a computed value, but only if boolean_expression evaluates to true
boolean_expression -> report an error when expression is false

(you could of course implement more sophisticated calculations, but these are relatively simple to do and solve many use cases)

Easy enough to do even with limited development time.
But i'm not even sure that is what is intended with the rule grammar, or that it is just meant to validate, or something else?

Regarding the strategies, one could easily do a strategy C:
Choose one language without any modifications (for example javascript/ecmascript) and define a few functions/methods to be available from there. For example with javascript, you could define the composition object, under a global variable, with the following methods:

composition.getValue(path);
composition.setValue(path, value);
composition.reportError(error); //could be a code in the terminology to translate
composition.show(path);
composition.hide(path); // or some other term, or setExistence, or ...
composition.query(...);

And you could do many things. Add a require-function and you could use external libraries.

That is rather easy to implement with of the shelf javascript tools - it's hard to find a development environment where you cannot in some way evaluate ecmascript/javascript.

So, what to do? :)

[wolandscat]

There are examples of archetypes containing rules that are parsed here.

So far I have not gone further on defining named variables. The discussion points that Borut raises are relevant here - how is the computing to be done? How much of this language do we (re)invent? Recreating a language isn't that hard, as long as the scope language is limited and we know what job we are trying to achieve.

The original intention with the rules part of an archetype was to allow the expression of constraints that cannot be expressed 'inline', typically constraints that range over disparate paths in the tree. See the above examples to get an idea. The original idea was not to compute guidelines, but rather to state validity conditions on the data. Now, if there is a mathematical relationship that has to hold for the data to be correct, e.g. the individual Apgar scores have to add up to the total, then the constraint statement has the same form as a statement designed to compute the result. If such a statement is understood as a constraint then the '=' symbol means 'is equal to'. If it is meant to be a computation then the '=' would be intepreted as an assignment, i.e. 'becomes' in the usual sense of a programming language.

Some people have said, ok, that means we need to support 'functions' i.e. formulae that do assign values to a field based on other fields; if we do that then we would limit the 'rules' to be purely assertions of whether some optional field exists depending on a value of another field etc.

This is the main source of confusion about the rules section in my view. I think the community still has not arrived at a consensus on these issues. I might post some of this on a wiki page and mention it on the discussion groups.