JSR 308 and implicit n-ary lambdas
Michael Ernst
mernst at cs.washington.edu
Thu Nov 8 08:53:51 PST 2012
Maurizio-
Thanks for these suggestions. Since you are more familiar with the lambda
parsing code, is it possible for you to take the first pass at generalizing
that code per your suggestions (that is, recording the annotation without
committing to a particular parse)?
> Also, we are adding support for intersection types in cast i.e.
> Object = (A & B)obj;
I believe that the answer is no -- intersection types are not written
explicitly by the programmer. Others can correct me if I am wrong.
Thanks!
-Mike
> Subject: Re: JSR 308 and implicit n-ary lambdas
> From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> To: Werner Dietl <wdietl at gmail.com>
> Date: Thu, 08 Nov 2012 13:36:07 +0000
>
> 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
More information about the type-annotations-dev
mailing list