JSR 308 and implicit n-ary lambdas
Werner Dietl
wdietl at gmail.com
Mon Nov 19 23:27:45 PST 2012
It looks like I didn't break most of the lambda tests after all - a
complete rebuild of all projects shows that the same 3/4 tests as
yesterday fail. I didn't think that the lambda tests might have been
affected by another repository.
See:
http://buffalo.cs.washington.edu:8080/job/type-annotations-langtools/65/
However, it would still be good to know whether to keep JavacParser
close to lambda or TL.
Thanks,
cu, WMD.
On Mon, Nov 19, 2012 at 8:19 PM, Werner Dietl <wdietl at gmail.com> wrote:
> There are still differences between the TL JavacParser and the one in
> lambda; most importantly, lambda uses the analyzeParens function,
> which I need to disambiguate casts/lambdas.
>
> cu, WMD.
>
> On Mon, Nov 19, 2012 at 8:14 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> I'm surprised to hear that the lambda parser is different from the
>> TL parser, since as far as I know, all the javac support for lambda
>> is now in TL.
>>
>> I guess I can compare the repos and get back to you; otherwise,
>> we'll have to wait for Maurizio's input tomorrow.
>>
>> -- Jon
>>
>>
>> On 11/19/2012 08:04 PM, Werner Dietl wrote:
>>>
>>> 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
--
http://www.google.com/profiles/wdietl
More information about the type-annotations-dev
mailing list