[type-annos-observers] Comments on the Nov 7 specification

[Werner Dietl]

Eric, all,

I see your point, but want to give two reasons why "inside-out" makes
more sense to me - one reason being the meaning of the types and the
other being the AST representation. I think the AST should be
considered as much as the bytecode representation.

1. Meaning of the nested types:
For a nested type, we can basically think of a type parameterized by
the outer type. This type parameter is what the programmer can access with
Outer.this.
So for the type:

@A Outer. @B Middle. @C Inner

we can think of the generic type:

@C Inner< @B Middle< @A Outer > >

For the generic type, the locations would be:

@A: 3(1), 3(1)
@B: 3(1)
@C: -

Similarly, with the "inside-out" approach, we would have:

@A: 1(0), 1(0)
@B: 1(0)
@C: -

With the "outside-in" approach, we would have:

@A: -
@B: 1(0)
@C: 1(0), 1(0)

That is, "inside-out" follows the logical structure of the generic
type correspondence, whereas "outside-in" breaks that order.


2. AST structure:
Even if we disregard this correspondence to the generic type as too
academic, I think the AST structure makes "inside-out" preferable.
For the type:

Outer.Inner.Middle

we roughly build the following AST:

    VARIABLE id: f
      MEMBER_SELECT expr: Outer.Middle id: Inner
        MEMBER_SELECT expr: Outer id: Middle
          IDENTIFIER Outer

That is, "Inner" is the root of the type, and "Outer.Middle" is the
receiver of the field select, and so on.
Similarly, for the type

@A Outer. @B Middle. @C Inner

we roughly build the following AST:

    VARIABLE id: g
      MODIFIERS
        ANNOTATION
          IDENTIFIER A
      ANNOTATED_TYPE
        ANNOTATION
          IDENTIFIER C
        MEMBER_SELECT expr: Outer. @B() Middle id: Inner
          ANNOTATED_TYPE
            ANNOTATION
              IDENTIFIER B
            MEMBER_SELECT expr: Outer id: Middle
              IDENTIFIER Outer

That is, type "@C Inner" is at the root of the tree and "Outer. @B
Middle" is the receiver expression.

In this AST representation, determining the nesting position is easier
if we can simply count how deep we descend in the tree to reach a
certain type.

I would be interested in hearing from people that use other ASTs
whether they have a similar issue.

Thanks,
cu, WMD.

On Sat, Nov 24, 2012 at 8:28 AM, Eric Bruneton <ebruneton at free.fr> wrote:
> 20/11/2012 21:37, Michael Ernst wrote:
>>
>> Eric Bruneton said:
>>
>>>  From an ASM point of view,
>>> ...
>>> The important
>>> point is that all paths should be "from outside to inside" (e.g. for
>>> nested
>>> types, the path should go from outer to inner, not the other way around
>>> as
>>> proposed in the Nov 7 specification).
>>
>>
>> Eric, I'm willing to make this change, but I would like to be able to give
>> a more specific justification for the design choice.  Can you explain the
>> rationale, or what difference it makes to ASM?  Is the reason that the
>> identifiers appear left-to-right in the class file and you want to process
>> them in that order, or is it something else?
>
>
> Right, it's basically that. For instance, consider the problem of extracting
> the part of a type signature in the class file format (e.g.
> Ljava.util.Map<+Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
> that corresponds to a given type_path. With 'outside to inside' paths, this
> can be done with a simple recursive function, like
> extract(signature,path)
> - if empty path return signature
> - otherwise parse the first signature element from the left, check
> conformity with first path element, and call recursively with tail of
> signature and tail of path.
>
> With 'inside to outside' paths, you have to parse the three inner types in
> the signature to realize that
> "inner_path{inner_path{inner_path{empty_path}}}", for instance, was in fact
> the first parsed type (then you either have to save state during parsing, or
> do another parsing pass).
>
> I'm not sure I'm clear, but I hope you get the idea.
>
> Eric



-- 
http://www.google.com/profiles/wdietl