JSR 308 and implicit n-ary lambdas

[Maurizio Cimadamore]

On 08/11/12 16:53, Michael Ernst wrote:
> 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)?
I can spend one day max on this (given all the other things I'm 
following at the moment); what exactly do you need?
>
>> 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.
We are adding limited support for them as part of Project Lambda. So you 
will be able to write them in the context of a cast expression.

Maurizio
>
> 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