JSR 308 and implicit n-ary lambdas

[Maurizio Cimadamore]

On 08/11/12 10:14, Werner Dietl wrote:
> Lambda experts,
>
> the parser in file 
> langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java around 
> line 968 contains the following:
>
>         case LPAREN:
>             if (typeArgs == null && (mode & EXPR) != 0) {
>                 if (peekToken(MONKEYS_AT) ||
>                         peekToken(FINAL) ||
>                         peekToken(RPAREN) ||
>                         peekToken(IDENTIFIER, COMMA) ||
>                         peekToken(IDENTIFIER, RPAREN, ARROW)) {
>                     //implicit n-ary lambda
>                     t = lambdaExpressionOrStatement(true, 
> peekToken(MONKEYS_AT) || peekToken(FINAL), pos);
>                     break;
>                 } else {
>
> this breaks in combination with type annotations on type casts.
>
> For an example failure, see this test case:
>
> http://buffalo.cs.washington.edu:8080/job/type-annotations-langtools/61/testReport/com.sun.tools.javac.annotations.typeAnnotations.classfile/TypeCasts/tools_javac_annotations_typeAnnotations_classfile_TypeCasts_java/
>
> In the above code, is the MONKEYS_AT used with the assumption that any 
> annotation after a LPAREN must be a declaration annotation on a 
> parameter and therefore a lambda should start?
Your assumption is correct - currently the only way an @ could occur 
inside a parenthesized expression is if a lambda parameter type was 
annotated; of course I see this creates issues with type annotations. We 
could remove that assumption from the parser, however note that a 
sequence of two identifiers is also a trigger for an explicit lambda.

Also you might want to look at the new parser code in the 
lambda-repository [1], which has an explicit disambiguation logic; 
perhaps it would be easier to make things work there by adding necessary 
rules for type annotations.


>
> In the following code:
>
> String a0 = (@A String) o;
>
> instead of looking for just the MONKEYS_AT, I think we will have to 
> parse a whole type and then see whether we hit an identifier (it's a 
> lambda) or a closing RPAREN (it's an annotated cast).
>
> Do you see a simpler way to disambiguate this? Am I misunderstanding 
> what's happening here?
One idea that comes to my mind would be to use the new lambda parser 
code and, in the disambiguation logic, add some code for essentially 
skipping through an annotation. I.e. an annotation should not cause the 
parser to take one route over another - but it certainly restricts the 
set of possibilities: i.e. either it's an explicit lambda, or an 
annotated cast. I think that the new disambiguation code could work 
_provided_ that the whole annotation is skipped before speculatively 
consuming the next token.

Also, we are adding support for intersection types in cast i.e.

Object = (A & B)obj;

Which probably further complicates things.

[1] - 
http://hg.openjdk.java.net/jdk8/tl/langtools/file/tip/src/share/classes/com/sun/tools/javac/parser/JavacParser.java

Maurizio
>
> Thanks,
> cu, WMD.
>
> -- 
> http://www.google.com/profiles/wdietl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20121108/fa7aca5b/attachment.html