Re: [abc] this afternoon

On Mon, 6 Dec 2004, Ondrej Lhotak wrote:

> On Mon, Dec 06, 2004 at 10:06:03AM +0000, Oege de Moor wrote:
> > on musketeer. Also read Sascha's wiki page at
> >
> > http://musketeer.comlab.ox.ac.uk/ProgToolsWiki/PlansForJava5
> >
> > or even better: add to it! I've added a few remarks about the
> > syntax for annotations in patterns.
>
> I expect the ajc team to reject the [] idea, because it violates an
> unwritten but so far consistently observed principle in the design of
> patterns: every signature is also a pattern matching itself.

Yes, that's a very strong argument. But I cannot see how to adhere to that
principle without creating a lot of problems. Also, are annotations
formally part of the signature?

> For the ugly case that this is trying to solve:
> (@Foo || @Goo A || B)
> why can't we just make the space between the attribute and the name have
> higher precedence than the ||? The above would then be a syntax error;
> we would force the parentheses:
> ((@Foo || @Goo) (A || B))

If that were the only problem, that would be fine as a solution.
However, there are the following other reasons to use a different syntax:

a) meta-annotations: @Foo[Goo][Bar]
   (inexpressible in the ajc proposal)
b) pattern expressions for annotations: @Foo*[Bar]
   (inexpressible in the ajc proposal)
c) clear distinction between "has annotation that is not Foo" and "does
   not have Foo annotation":
     @!Foo[Bar] : Bar has annotation that is not Foo
     !@Foo[*] && Bar : Bar that does not have Foo annotation
   We decided to add "(!@Foo)[Bar]" as shorthand for the latter -
   cf the throws patterns in aspectj.
d) Simple notation to specify annotations on packages in patterns:
     @Foo[@Bar[xyz].abc].C*
   (class whose name starts with C in a package xyz.abc with
   annotation Foo, where xyz has annotation Bar.

> Also, in general, are we trying to come up with a grammar extension that
> is unambiguous in relation to the Java 1.4 grammar, or in relation to
> the Java 1.5 grammar? It seems the latter would be more appropriate, but
> the former seems to be what you guys are discussing.

Yes, that is right of course. We need to start somewhere, though, so I
was just tinkering with the grammar we've got. It would be nice if we
already had a 1.5 frontend to tinker with!

> Hopefully, there
> won't be too many problems with ambiguity because of the parser state.

I don't think that poses any new problems.

-O
Received on Mon Dec 6 16:38:58 2004