Re: [abc-dev] Cflow extension and small problem with polyglot

Hi,

Thanks a lot for this very detailed answer.
I like the idea of binding parameters (it would also probably be a good
application of the private pointcut variables described in the AOSD'2005
paper). I'm not quite sure how it would affect the performance. In my
sketchy prototype, I'm only using a field in the poincut class, and the
value of the test is "hard-woven" by the corresponding CflowCodeGen.
I'm a bit worried that binding a variable would incur extra runtime
tests and overhead. Maybe combining this approach with the technique
described in Aotani and Masuhara's SPLAT'2005 paper ("Compiling
conditional pointcuts for user-level Semantic Pointcuts") would be a
good solution.

I don't think I'm going to have time to investigate this much further in
the near future. However, I have made the extension available at:
http://www.cs.manchester.ac.uk/cnc/projects/loopsaj/cflowlevel/
It comes with a modified version of abc. (The modifications are minor
and only consist of changing the visibility of some class members to
"public", because otherwise they cannot be used from the package
containing the cflowlevel extension.)
If this seems interesting, feel free to get in touch ;-)

Regards,

Bruno.

-- 
Home page: http://www.cs.man.ac.uk/~harbulob/
LoopsAJ: http://www.cs.manchester.ac.uk/cnc/projects/loopsaj/
Pavel Avgustinov wrote:
> Hi,
> 
> The reason for this is actually not Polyglot but our lexer.
> 
> I don't know how familiar you are with it. We use a stateful lexer to
> allow us to recognise different keywords in different contexts. In
> particular, we have the states YYINITIAL (which is essentially Java,
> plus some special keywords like 'aspect' and 'pointcut'), ASPECTJ (used
> for "proper" AspectJ code, with things like 'declare parents'), POINTCUT
> (used for, obviously, pointcuts) and POINTCUTIFEXPR (which is kind of a
> special case of YYINITIAL -- that state is used to lex the java fragment
> in an if() pointcut. We can't use the 'proper' Java state since this
> state is terminated by a matching closing ')', while YYINITIAL isn't.
> 
> There are various keywords that cause transitions between the states.
> 
> Now, the problem at hand: Integer literals are handled just after line
> 600 in aspectj.flex, with the line that your '2' should be matched by
> being 605. However, if you scroll up, you'll find (line 513) that all
> these lexemes are only defined for the states YYINITIAL, ASPECTJ and
> POINTCUTIFEXPR. It seems that, since 'normal' pointcuts don't allow
> numeric literals, our lexer doesn't recognise them in the POINTCUT
> state, which it is in when it reads your cflowlevel(2,executerun()).
> 
> This is a little bit unfortunate, since our lexer extensibility
> mechanism doesn't at the moment provide a way of adding new non-keyword
> lexemes to states. I see two approaches one could take to fix this.
> Either duplicate the .flex file and add the integer literal productions
> to the POINTCUT state somewhere (this should definitely work, but has
> the disadvantage of your extension using a duplicated file, which you'd
> have to keep in synch with main abc manually), or try to fiddle the
> contents of a cflowlevel() to be parsed in POINTCUTIFEXPR state. I'm not
> entirely sure if something like "2, executerun()" is a syntactically
> valid Java fragment, however, so that approach may not work with the
> current syntax.. At least it'd be easy to make the lexer switch to
> POINTCUTIFEXPR state (check how the "if" keyword is handled in
> abc.main.AbcExtension). Taking that approach would allow an arbitrary
> syntactically valid fragment of Java code as the parameter of
> cflowlevel(), so you'd have to do some additional checks to make sure
> it's the right format.
> 
> Briefly discussing this with Julian, he suggests that making cflowlevel
> *bind* the level would be more "AspectJ-like", for good or bad. So
> "cflowlevel(2, executerun())" would become "cflowlevel(i, executerun())
> && if(i == 2)". This would give you the 'greater-than' and 'less-than'
> constructs for free.
> 
> Hope this is of some help.. If you'd like to discuss this further,
> please feel free. :-)
> 
> - P