JSR 308 and implicit n-ary lambdas

Thu Nov 8 10:04:25 PST 2012

Sorry, I gave you the wrong pointer - the new parser is here:

http://hg.openjdk.java.net/lambda/lambda/langtools/file/tip/src/share/classes/com/sun/tools/javac/parser/JavacParser.java

[in the lambda repository]

This  is slightly different (and more powerful) from the one in JDK8/TL.

I have a patch based on this parser code that should be helpful - I'm 
currently testing it to see if it doesn't break anything ;-)

I will send you the patch once testing is complete.

Maurizio

On 08/11/12 17:58, Werner Dietl wrote:
> 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

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