RE: [abc-dev] New Publication: Implementing concern-specific languages with ABC

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Ganesh.

Ganesh Sittampalam wrote:
>> compilation process. Also I tried to reflect on the effort I had
>> to overcome while using ABC and give some advice on possible
>> improvements.
>
> One of the (entirely justified!) criticisms you make is of the lack
> of comments, and that's something we do work on when we have time.
> If you'd like to identify specific places where more comments would
> be helpful, we'll try to give those areas special attention. You
> could even supply some yourself based on your own understanding of
> the code :-)
Maybe I could. I will see, what I can do ;-)
I think the major problem I am having at the moment is that I don't
really understand what all the various compiler passes are actually
doing. Comments like "definite initialization" (ExtensionInfo) don't
really tell developers a lot. It would be great if there was a
detailed outline of what happens during the ast rewrites, what the
requirements are for each rewrite, what the result is and what syntax
errors could cause the pass to fail.

Also I could not find any high level documentation that tells in what
order passes are invoked and if they may interleave etc. I noticed
there are barrier passes, so there must be some kind of interleaving
thing going on between barriers, or did I understand wrong here? Is
the loop "for each pass apply pass on each ast..." or "for each ast
apply each pass on it" ? So in general a document outlining the majpr
control of abc would be great.

Another thing is the dependency between the actual AST and what you
cann AspectInfo (or weaving info). If I understand correctly the
former reflects the syntactical structure and the latter gives
instructions of how this syntactical structure is to be implemented
by the weaver. However, the link between both worlds is not very
obvious. I could not actually find any position at once, where code
was jimplewise woven (certainly I did not search hard enough ;-) ).
So it would be good to have a documentation of how both worlds are
connected. Maybe a document that just tells how a single named
pointcut and a piece of advice are lexed/compiled/woven would already
clarify a lot. So just documenting what passes are applied, what the
passes do with the pointcut/advice and how finally the jimple rewrite
is triggered.

>> However, it would be great if you had any comments about this
>> work.
> You use a separate bytecode analysis tool to read in Java 5
> > annotations from compiled bytecode. Could this stage have been
> avoided if abc supported Java 5, so that the annotations would
> presumably have been available from the source?

It depends. I want annotations to be drawn from *bytecode*, not
source code. Otherwise I could also have used an annotation provider
for the Java "apt" tool (Sun). If abc could provide this (similar to
AspectWerkz, which has an API for this), that would be great. The
current solution uses an class to XML rewrite and then reads the XML
in again, which is not really the most efficient solution.

I should also mention that the search path for those annotations is
neiter aspectpath nor inpath nor classpath. I added another one
"ltlpath", which holds classes to draw the LTL annotations from.
Extending the options xml file was handy but also not very extendible
since I had to copy it. If you now make changes to the options they
won't automatically go into my options file, too.
Also I would like to see a means of having options per extension.
"-ltlpath" should only be available with "-ext abc.ltl". Currently I
see no way of doing this.

> You also mention that improving lexer extensibility to allow extra
> states to be added would be useful. Can you give examples of how it
> would help you?
In my specific case I could model the whole LTL formulas as pointcut
so "enhancing" the pointcut state with my additional keywords worked
fine. But if you take other language extensions, e.g. Rob Walker's
tracecuts, I am pretty sure, you wanna have a distinct tracecut state
since e.g. some keywords in tracecuts could be identifiers in usual
pointcuts. I know adding states is not an easy thing (and probably
not the most urgent one either). But it would be nice as future work
in my eyes.

> I also realised from reading your comments about modifying the ant
> build file that this part isn't very extensible! Of course it's a
> fairly trivial task, but perhaps it should be. I'm inclined to
> suggest that extensions should be compiled into separate jar files
> to abc itself, but of course it would then be a bit more of a
> nuisance to use them.
Well it depends on what people want. Sometimes it makes sense (And is
actually pretty nice) to ship the whole lot as a single jar file. Of
course for maintainability reasons it would be great if people could
upgrade the backend of let's say my "LTL verifier" to a new abc
version by just swapping a "abc base" jar (whereas the ltl specific
code remains in a specific jar). I guess developers should have both
options.

Would it not be possible to have a distince "extension descriptor"
that would parameterize an XSLT transform to *produce* an ANT script
specific to this extension. Maybe the ANT scripting language is also
rich enough itself to give more extensibility. I am not such an ANT
guy, don't really know.

>> Also if you would like to link the works from your ABC website,
>> feel free to do so.
>
> We'll add a new section for this kind of thing as soon as we get a
> chance :-) Do you plan to make your extension available?
Yes, I am certainly going to. However, the major work (the AST
rewrites from my pointcut language to plain AspectJ) is not yet
finished. I am planning a release for early summer. I hope I can rule
out the last problems with some of your people at Chicago.

This topic is my diploma thesis, so there is also still another big
publication going to come.

Thanks a lot for your feedback.

Eric

- --
Eric Bodden
Chair I2 for Programming Languages and Program Analysis
RWTH Aachen University

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQgOqsswiFCm7RlWCEQLMFQCeNx8KiApkMlh/3tvqHuANkBfjSl0AnA1A
aVNgUqh/NueN66r+R1QZIJ4c
=dGPu
-----END PGP SIGNATURE-----
Received on Fri Feb 4 17:03:17 2005