JSR 308 and implicit n-ary lambdas
Werner Dietl
wdietl at gmail.com
Mon Nov 19 20:04:18 PST 2012
Maurizio, Jon,
I just merged with jdk8/tl, but this unfortunately results in many
failures with lambda.
I expect I did something wrong when merging JavacParser, but am not sure what.
The type-annotations parser is still very similar to the lambda parser
and I didn't see a problem there.
However, the parser in jdk8/tl contains a few big differences.
On which parser should I base the type-annotations parser?
Is the lambda repository dead now and I should only look at jdk8/tl?
Thanks,
cu, WMD.
On Fri, Nov 9, 2012 at 6:03 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> 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
>>>
>>>
>>
>>
>
--
http://www.google.com/profiles/wdietl
More information about the type-annotations-dev
mailing list