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

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Sina,

Thanks for the update. If you don't manage to get this to work within
the next few days please let me know and we can have a look at this
together.

Cheers,
Dimitris

On Wed, 9 Jan 2019 at 16:38, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:
>
> 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



-- 
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos

EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm