[epsilon-dev] Mixing simple and lambda parameters in operation calls

[Sina Madani <sinadoom@xxxxxxxxxxxxxx>]

Hi all,

 

I have been working on a solution to the limitation of EOL’s grammar in resolving simple (i.e. ordinary object parameters) and complex (i.e. lambda parameters) in operation calls. Currently parameters after the lambda(s) are handled fine by FirstOrderOperationCallExpression (for example, Sequence{0..10}.nMatch(i | i > 4, 6)) but parameters before the first lambda are parsed as being part of the lambda (for example, Stream.iterate(1, i | i * 2)) . My proposal (already implemented and tested, just not committed to main branch) is to introduce a ComplexOperationCallExpression to overcome these shortcomings. Now not only will simple parameters and lambda parameters be distinguishable, but the scope of lambda parameters can also be limited to each individual lambda as opposed to being available in all of them, since FirstOrderOperationCallExpression / declarativeFeatureCall (in the grammar) were not really designed for multiple lambda expressions and arbitrary interleaving of lambdas and simple parameters. The parser and DOM can now handle complex operation calls such as the following:

 

target.complexOperation(op1, op2, [lp1 | lp1.foo()], op3, [| “hello”], [lp1, lp2, lp3 | lp1.doSomething(lp2, lp3)], op3);

 

or for the simple example: Stream.iterate(1, [i|i*2]);

 

Implementation-wise, ComplexOperationCallExpression is a FeatureCallExpression with a NameExpression (the operation to call), targetExpression (the object to invoke the operation on) and a LinkedHashMap<_expression_, List<Parameter>> which limits the scope of lambda parameters to their respective expressions. Non-lambda expressions (i.e. those to the operation itself) will be mapped to null. Execution is then handled by DynamicOperation. There is one limitation however. For some reason allowing multiple “logicalExpression”s before the lambda causes strange behaviour in the parsing which breaks some scripts, so any parameters before the lambda must be a NameExpression, so the above example would have to become:

 

var seed = 1;

Stream.iterate(seed, [i|i*2]);

 

Grammar-wise, the changes are an additional alternative to featureCall (“complexFeatureCall”), a “lambdaExpression” rule and a new “LAMBDAEXPR” token associated with that rule.

 

If there are no objections or suggestions for improvement I propose to push these changes to master. As this requires a change to the grammar and parsers I thought I would check first if there is anything else to be aware of regarding such a change.

 

Thanks,

Sina