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

[Sina Madani <sinadoom@xxxxxxxxxxxxxx>]

Hi Dimitris,

 

Sorry for the late reply, I only saw your e-mail when checking the mailing list archives. Yes, it is possible to use either parentheses or square brackets for grouping / distinguishing lambda expressions. I have also discovered that parameters prior to the first lambda need not necessarily be NameExpression, but anything that doesn’t involve referencing logicalExpression. Currently the new rules are as follows:

 

complexFeatureCall

    @after {

       $tree.getExtraTokens().add($op);

       $tree.getExtraTokens().add($cp);

    }

    :   NAME^ op='('! complexParameterExpressions (',' complexParameterExpressions)* ','! lambdaExpression (','! (logicalExpression | lambdaExpression))* cp=')'!

    ;

 

complexParameterExpressions

    :   NAME | literal | nativeType | pathName

    ;

 

lambdaExpression

    @after {

       $lop.setType(LAMBDAEXPR);

       $tree.getExtraTokens().add($lop);

       $tree.getExtraTokens().add($lcp);

       $tree.getExtraTokens().add($lt);

    }

    :   (lop='['^ formalParameterList? (lt='|'! | lt='=>'!) logicalExpression lcp=']'!) |

       (lop='('^ formalParameterList? (lt='|'! | lt='=>'!) logicalExpression lcp=')'!)

    ;

 

I have spent some time trying to figure out why complexParameterExpressions is necessary and the consequences of replacing it with logicalExpression, with little luck. It seems to impact assignments to variables such as:

var x = First!EClass;

var oldName = ecore::EClass.all.first.name;

 

with “no viable alternative at input” message during parsing. I suspect there is either an obscure bug in ANTLR or something in the grammar which confuses the parser when adding this alternative. However the current version as outlined above seems to be working and all tests passing. I will try to investigate further at some point.

 

Thanks,

Sina