JSR 308 and implicit n-ary lambdas
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Nov 20 01:49:30 PST 2012
On 20/11/12 04:04, 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?
The lambda parser in TL is different from the one in lambda-repo (which
is the one I suggest you use). The version in the lambda-repo is a more
advanced version that is capable of handling more complex stuff (such as
intersection types in cast) - that's the one you would use should you
want to add support for type annotation in cast. The new parser code is
currently under review - we will push it as soon as it is ready for
primetime.
Thanks
Maurizio
> 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
>>>>
>>>>
>>>
>
>
More information about the type-annotations-dev
mailing list