JSR 308 and implicit n-ary lambdas

[Werner Dietl]

Hi Maurizio,

thanks for these clarifications!

> 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.
>
> [1] -
> http://hg.openjdk.java.net/jdk8/tl/langtools/file/tip/src/share/classes/com/sun/tools/javac/parser/JavacParser.java

I'm not sure what you mean with "new lambda parser code" and the
earlier " lambda-repository [1]". I merged with jdk8/tl/langtools, so
the parser in type-annotations should be based on the same code.
Should I pull from some other repository to get a newer parser? Will
this newer parser become the default in jdk8/jdk8?

It would be great if you could spend some time in the type-annotations
repository and see whether you can disambiguate the grammar. I think
for you this should be a lot quicker than a day.
If not, a pointer to what functions to look at would be helpful.


> Also, we are adding support for intersection types in cast i.e.
>
> Object = (A & B)obj;
>
> Which probably further complicates things.

I assume we also want to be able to annotate each sub-type, as in:

Object o = (@TA1 A & @TA2 B) obj;

Are there any other locations in the grammar where MONKEY_AT is now
interpreted differently or where you think we might not have
considered type annotations yet?

Thanks!
cu, WMD.



On Thu, Nov 8, 2012 at 5:36 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> 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
>
>



--
http://www.google.com/profiles/wdietl