Re: [abc] /me talks to himself on irc

On Wed, Sep 22, 2004 at 06:53:45PM -0400, Prof. Laurie HENDREN wrote:
> I think the paper is missing the front-end .... where we motivate
> and set up the problem, introduce our goals, define what good
> extensibility would be, and define the 6 (or whatever it is ...)
> main steps to defining an extension using our approach ...
>
> Here is what I have in mind, please comment:

In general, I think it's a very nice structure, and I think it addresses
the problems I was talking about on irc. See, like I said, all it needs
is a six-page introduction, and it will be fine. :-)

> 1) Introduction and Motivation
> - Aspect oriented programming is a new field which is rapidly
> developing.
> - AspectJ is a widely accepted aspect-oriented language.
> - In order to experiment with new aspect-oriented concepts and
> associated language constructs, it would
> be beneficial to have a compiler for AspectJ that was easy to
> extend.

I would switch the order of the last two points, but that's a minor
thing. First say we want a platform to experiment on, then say it's
based on AspectJ because it's a widely accepted language.

> - Many such extensions have been proposed .... talk about a few.

We should mention some of the difficulties that the implementors of
these extensions ran into.

> - The AspectJ compiler, ajc, has not been designed with
> extensibility in mind because it has many other important
> design goals, namely it must closely integrate with
> the Eclipse platform and must support fast and incremental
> compilation.

This is a good point: rather than saying abc rocks and ajc sucks, point
out that there were different design goals, and that's why things are
the way they are. This also makes it less necessary to justify some of
the drawbacks caused by our design goals (incremental compilation).

> - The ApectBench compiler, abc, is a completely new implementation
> and has been designed from the beginning with extensibility in mind.
>
> 1.1) Design goals, in terms of extensibility:
>
> simplicity: it must be relatively simple develop new
> extensions
>
> modularity: extensions should be modular, and should not
> require rewriting of existing code
>
> proportionality: small extensions should require a small amount
> of work/code

Hmm... Simplicity and proportionality seem quite similar, and modularity
is closely related. Modularity is probably OK, but I don't think we
should have both simplicity and proportionality. On the other hand,
having five or more is good. So I think we should come up with some
more. I have one: completeness, or something like that. If I understand
correctly, many of the existing extensions were implemented on toy
languages. However, you really want to be able to implement things on
a complete language so that you can try them out on full-sized
real-world benchmarks. Now we just need a synonym for completeness that
ends in y.

> efficiency: it should be possible to provide efficient
> implementations of new extensions
>
> composability: ideally, one would like to be able to
> compose several extensions
>
> 1.2) Our approach (and related back to 1.1).
>
> - build on existing tools for the front-end and back-end that
> help us reach our goals of 1.1
>
> Polyglot - already supports simple, modular and
> proportional front-end extensions.
>
> Soot - already supports a simple IR, modular analyses,
> and support for producing efficient code.
>
> - design an architecture for abc that:
> - uses the vanilla versions of polyglot and soot (hence
> leading to our aspectinfo approach)
>
> - structures the compiler to that each key phase is
> extensible, including the matcher and weaver
>
> - illustrate the extensibility by implementing eaj, which
> extends AspectJ with four new features (list them here)

We'll need to be careful not to repeat things too much. But it seems to
work better if we first write it so it makes sense, and then go through
at the end removing repeated things.

> 1.3) What are our contributions.

I guess the two main ones are the compiler itself, and proof-of-concept
extensions that show it's extensible. Under the compiler itself part,
we should relate it in some detail to the points in section 1.1.

> 1.4) Structure of the rest of the paper.
>
>
> 2) Background - Soot, Polyglot, Basic abc architecture
>
>
> 3) Building an extension - the basic steps.

Is this going to be a fairly long section (with details on what needs to
be done), or just a short summary with the main guts in 5? I think lots
of detail should go here; the trick is that we can't use eaj as an
example at this point, so we can't explain things in terms of it. But I
think it's important to have an extensive part of the paper where things
are explained just on their own, without refering to the specific
extensions.

> 4) eaj - An AspectJ extension

This part fits very well in here, I think.

> 5) Implementing eaj using abc. (How-examples of basic steps)
> (How did it work? How much code?)

Some of the stuff from the current version of this will need to be made
independent of the extensions themselves and moved to 3. But the
examples that are in there now should fit naturally in here.

> 6) Related Work
>
> 7) Conclusions and Future Work
>
> +-------------------------------------------------------------+
> | Laurie Hendren, Professor, School of Computer Science |
> | McGill University |
> | 318 McConnell Engineering Building tel: (514) 398-7391 |
> | 3480 University Street fax: (514) 398-3883 |
> | Montreal, Quebec H3A 2A7 hendren@cs.mcgill.ca |
> | CANADA http://www.sable.mcgill.ca/~hendren |
> +-------------------------------------------------------------+
>
> On Wed, 22 Sep 2004, Ondrej Lhotak wrote:
>
> > I spewed out some comments about the paper on irc. I kept going for
> > quite a while before I realized that I was talking to just myself and
> > Julian. I'm sending out a copy so all of you can listen to me talk to
> > myself.
> >
> > 16:22 < hendren> I'm thinking now ...
> > 16:27 < olhotak> Hmm... I see that it's not easy to organize this paper.
> > 16:36 < olhotak> OK, I'm done reading the paper.
> > 16:37 < olhotak> It strikes me as somewhat backwards (maybe reading it from the end would have helped). I see the difficulty as a tension between the example
> > extensions themselves, and the extensibility of abc in general.
> > 16:38 < olhotak> Explaining the examples first really puts the focus on them, and makes the whole paper feel like the examples are the only contribution.
> > 16:38 < olhotak> However, we need to say something about the examples first, because we use them to illustrate how extensions are done, throughout section 4.
> > 16:39 < olhotak> But, if we just say something brief about them, then we haven't really done the examples justice.
> > 16:41 < olhotak> I mean, it *is* significant that the examples are actually real, useful things.
> > 16:42 < olhotak> And it doesn't make sense to just say something brief about them at the beginning, then describe them a second time yet again.
> > 16:42 < olhotak> I think a big weakness is that section 4 is written heavily in terms of the examples, rather than in general terms.
> > 16:43 < olhotak> If it explained what can be extended, why it should be extended, and how it is extended in general terms (within each subsection), followed by
> > a small demonstration of how specifically it's done for the examples, that would help a bit.
> > 16:43 < olhotak> I'm not sure if it would help enough, though.
> > 16:44 < olhotak> Am I just talking to myself here?
> > 16:48 -!- cgoard [cgoard@string.CS.McGill.CA] has joined #abc
> > 16:48 < julian_> olhotak : nope, we're listening
> > 16:49 < julian_> well... I am
> > 16:49 < olhotak> Well, Laurie and Heffie are gone.
> > 16:49 < julian_> oh
> > 16:49 < olhotak> I think I'll put my musings into an e-mail for everyone.
> > 16:50 < olhotak> julian_: I think it's important to show the extensions in detail in the paper, because they're significant and it's important to show that
> > they're significant.
> > 16:51 < olhotak> But on the other hand, we need to convince people that it's more general than *just* those extensions.
> > 16:51 < olhotak> I'm not quite sure how to do both at the same time.
> > 16:51 < olhotak> Hopefully the others will have an idea.
> > 16:51 < julian_> I know what you mean. There is a lot of implementation detail. Wood hiding the trees kinda stuff
> >
> > Ondrej
> >
> >
>
>
Received on Thu Sep 23 01:13:53 2004