JSR 308 and implicit n-ary lambdas

Fri Nov 9 06:03:26 PST 2012

On 09/11/12 03:34, Werner Dietl wrote:
> Maurizio,
>
> I merged in some changes from lambda/lambda and applied your patch.
> This successfully disambiguates casts and lambdas and those errors are
> gone (I need to adapt a few more test cases).
>
> Thanks for your quick help!
> cu, WMD.
I'm glad it worked out ok!

Maurizio
>
> On Thu, Nov 8, 2012 at 11:33 AM, maurizio cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> On 08-Nov-12 6:30 PM, Werner Dietl wrote:
>>
>> Thanks a lot for this patch!
>>
>> Is it safe for me to pull in the whole lambda/langtools repository or should
>> I just selectively merge the JavacParser?
>>
>> Better just to pull the parser alone.
>>
>> Maurizio
>>
>>
>> cu, WMD.
>>
>>
>> On Thu, Nov 8, 2012 at 10:22 AM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> 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
>>>
>>>
>>>
>> 308
>>
>> --
>> http://www.google.com/profiles/wdietl
>>
>>
>
>