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

On Wed, 22 Sep 2004, 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:
>
> 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.
> - Many such extensions have been proposed .... talk about a few.

What sets abc apart from most extensible AOP frameworks is that
we cover extensibility in all dimensions, not just (say) in
pointcuts. To stress that, we should give a few examples of
each kind of extension, ranging from little syntactic variations
to features that require sophisticated analysis:

    - name pattern scopes [Colyer & Clement, AOSD 2004]
      Abstraction mechanism for name patterns, to avoid
      repeatedly writing verbose name pattern expressions.
      Requires easy modification of syntax. Pattern matcher
      needs environment to look up abbreviated patterns.

    - parametric introductions [Hanenberg, AOSD 2003]
      extension to itd mechanism, where parameters of itd
      are filled in based on characteristics of host class.
      Considerable complication of typechecking: requires
      highly flexible frontend. No interaction with
      advice weaving.

    - association aspects [Sakurai, AOSD 2003]
      Generalisation of per-object instantiation, useful
      to support behavioral relationships, in particular
      in system integration. Requires new code generation,
      in particular it complicates the implementation of
      around/proceed.

    - predicted cflow [Kiczales, keynote AOSD 2003]
      new pointcut: pcflow(p) matches at a joinpoint that *may*
      have a descendant that matches p. Useful for incremental
      updating of data structures. It is ok to match always,
      but that would lead to inefficient programs. A good
      implementation requires a precise static
      approximation of joinpoint graph.

    - dataflow pointcuts [Masuhara ...]
      New pointcut for tracking data dependencies, useful
      in security applications. Again requires sophisticated
      analysis for efficient implementation.

    - trace-based aspects [Douence et al, Walker & Viggers]
      Pointcuts can query history, not just individual
      joinpoints. Useful for protocol implementation, and
      various design patterns. Naive implementation runs a
      trace parser alongside every program; efficient
      implementation requires interprocedural analysis.

Revisit these at the end of the paper.

> - 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 our line, but not that of the ajc designers. We must
contrast what happens in ajc with what happens in abc.
The most common reaction to abc remains: why don't you just extend
ajc? I want the paper to give a technical answer.

> - 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

I agree with Ondrej that this one is too similar to the earlier ones.
Simplicity and modularity say it all.

> efficiency: it should be possible to provide efficient
> implementations of new extensions

Perhaps it would be better to set this up as:

            analysis: it should be possible to give modular
            implementations of analyses for the efficient
            implementation of new extensions.

I would have liked a point about compile-time efficiency, as that is the
perennial sticking point with extensible language implementations. The
problem is, we don't meet that criterion yet!

> composability: ideally, one would like to be able to
> compose several extensions

This one is important, but we don't meet it, and neither does Polyglot.
I suggest we move it to the discussion & future work section. I don't
believe it can be met with the Polyglot extension mechanisms.

> 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)

Stress that abc is itself a polyglot extension.

>
> - 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)
>
> 1.3) What are our contributions.
>
>
>
> 1.4) Structure of the rest of the paper.
>
> 2) Background - Soot, Polyglot, Basic abc architecture

I like this section as it is now.

> 3) Building an extension - the basic steps.

Right, just a generic description here.

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

> 6) Related Work

Need to say more here, including that (brrr) Xquery paper.

> 7) Conclusions and Future Work

A key question to answer: would abc be more extensible if it was itself
written using aspects?

> +-------------------------------------------------------------+
> | 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 11:38:30 2004