JSR 308 and implicit n-ary lambdas

Thu Nov 8 10:22:10 PST 2012

This patch passes all the tests I could throw at it :-)

As I said before, it is based on the JavacParser available in the lambda 
branch; I believe now the differences between the lambda version and the 
JDK 8 version are few enough that you shouldn't have problems merging 
those changes in. In order to apply the patch you need first to update 
the parser code to match what's available in the lambda repository.

With the patch, the parser now should apply a disambiguaton logic that 
is more 308-friendly (I hope!).

Maurizio

On 08/11/12 18:04, Maurizio Cimadamore wrote:
>
> 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/a795cfdd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: type-anno.patch
Type: text/x-diff
Size: 2301 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20121108/a795cfdd/type-anno-0001.patch 