[aspectc-user] Cooperation with "CTL-VW"?

[Christoph Borchert]

Hello Markus,

On 09.04.2014 21:58, Markus Elfring wrote:
>>> Would it be useful to reuse it in your function/class library?
>>
>> No, I don't think so (if I understood your idea correctly).
> 
> Thanks for your feedback.
> 
> Is the technology "computation tree logic" generally useful for parsing and
> transformation of source files?
> 
> 
>> A technical reason is that their tools are made for transforming C-code (mainly
>> the Linux kernel) and not for C++ code. They simply wouldn't work for us.
> 
> I know that also because of Coccinelle's software limitation to process C source
> code mostly.
> 
> 
>> Another reason -- on a higher level --  is that the pattern matching language
>> described in the paper is made for "semantic patches". This has similarities with
>> aspect weaving, but also subtle differences.
> 
> How do you think about discuss such differences a bit more?
> 
> 
>> Aspects are mainly made for "programming", whiles patches are made for modifications
>> in "existing code". Therefore patches need (in my opinion) much more fine-grained
>> code transformation abilities. I doubt that it makes sense to give an AO language,
>> for instance, the ability to transform specific expressions in specific functions.
> 
> Is there any more research going on about the expressiveness of poincut languages?
> 
> 

Well, there is a large body of work in the AspectJ community. For
example, LogicAJ features free variables ("meta variables"), which are
bound to values by the evaluation of logic predicates, in both the
pointcut language and the advice bodies. This is clearly an advancement
over the AspectC++ wildcard-based pointcut matching. I suppose this is
very similar to CTL-VW. We would also like to see such a feature in
AspectC++, however, our manpower is currently very limited, so that such
a "big" extension is not going to be implemented soon.

>> In the case of aspects, which are intended to live longer than patches, maintainance
>> problems might arise.
> 
> I guess that corresponding implementation details will need further considerations.
> 
> http://doi.ieeecomputersociety.org/10.1109/TSE.2011.21
> 
> 
>> Having said that, I would like to add that I am not against changes or
>> improvements to the AspectC++ pointcut language! On the contrary -- we already
>> have some ideas in this direction, which would give you more powerful means to
>> describe related joinpoints.
> 
> I am curious how the software development will evolve there.
> 
> 
>> However, we first have to finish the front-end migration to Clang, which is much
>> more important for the adoption of AspectC++ at the moment.
> 
> Would you like to share any more thoughts on this area?
> 

We have almost finished the migration to the Clang front end, which will
allow for C++11 code to be parsed. However, this does not come with an
AspectC++-language extension.

Best regards,
Christoph