RE: [abc] this afternoon

> -----Original Message-----
> From: Majordomo list server
> [mailto:majordomo@comlab.ox.ac.uk] On Behalf Of Oege de Moor
> Sent: Monday, December 06, 2004 5:39 PM
> To: abc@comlab.ox.ac.uk
> Subject: 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.
>
There was another example we discussed, that is the distinction between
annotations of formal parameters themselves vs. annotations of the types
of parameters. I think the proposal was as follows:
e) @Foo[*] @Bar : Any type with annotation Foo, plus Bar as the
annotation of the parameter.

Sascha

> > 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 17:03:54 2004