DMN13 — example shows literal inline function definition whereas grammar says function definitions only in boxed expressions.

The spec example shows a function definition inline in a literal expression using sort(). My take on the FEEL grammar spec is that a function definition can only exist inside a boxed expression, not inside a literal expression. A function definition inside a literal expression whose body has names with spaces or additional characters makes the parsing of the entire expression before execution darn hard - we'll I haven't figured it out anyways.

In the specific case of the sort function, the type of the 'list' parameter may only be known at execution time, and thus the types of the arguments to the 'precedes' function can only be known at execution time - that is, when actually executing the sort. And to execute a sort, you need to pass it its arguments - which means a parsed function definition. If that function definition has names with spaces, then parsing can't be done until the types are known - during the sort execution. A little bit chicken an egg.

But, if I read the spec correctly, you should not be able to have a function definition inside a literal expression. In which case, it is parsed separately to its invoking function and the above is not an issue.

As a note, the given example and some tests in the TCK (which I am not sure should be there) involve simple params or simple names and can be parsed. But the scenario above is not covered by the TCK.

Happy to be guided otherwise. An all advice appreciated.

change grammar rule 2.h. in ch 10 to use expression instead of textual expression

see revised text