Control Invocation Syntax++

[Peter Levart]

On Wednesday 23 December 2009 07:26:28 Neal Gafter wrote:
> > Next, instead of "ControlInvocationStatement" I would propose "ControlInvocation" expression (being one of possible "Primary" expressions):
> >
> >    ControlInvocation:
> >        [for] MethodName ( FormalParameters [: ArgumentList] ) ParExpression
> >        [for] Primary [. NonWildTypeArguments] Identifier ( FormalParameters [: ArgumentList] ) ParExpression
> >        [for] super [. NonWildTypeArguments] Identifier ( FormalParameters [: ArgumentList] ) ParExpression
> >        [for] ClassName . super [. NonWildTypeArguments] Identifier ( FormalParameters [: ArgumentList] ) ParExpression
> >        [for] TypeName [. NonWildTypeArguments] Identifier ( FormalParameters [: ArgumentList] ) ParExpression
> >        [for] MethodName ( [ArgumentList] ) ParExpression
> >        [for] Primary [. NonWildTypeArguments] Identifier ( [ArgumentList] ) ParExpression
> >        [for] super [. NonWildTypeArguments] Identifier ( [ArgumentList] ) ParExpression
> >        [for] ClassName . super [. NonWildTypeArguments] Identifier ( [ArgumentList] ) ParExpression
> >        [for] TypeName [. NonWildTypeArguments] Identifier ( [ArgumentList] ) ParExpression
> 
> These are all ambiguous with the idea of being able to invoke an
> expression of function type without the ".invoke".
> 

Oh yes, I see. As much as ParExpression and ArgumentList are ambiguous.
It seams we're out of good unambiguous syntax variations.

But what about the idea of ParExpression alone:

   ParExpression:
       ( [BlockStatements] Expression )
       ( BlockStatements )

It would simplify expression lambdas when they are not used as functions but only as transparent closures. That's something BGGA has and although it is perceived as "strange" syntax, I like it.

Peter