[abc] comments from Chris

---------- Forwarded message ----------
Date: Wed, 29 Sep 2004 13:22:00 +0100 (BST)
From: Christopher Allan <christopher.allan@somerville.oxford.ac.uk>
To: Ganesh Sittampalam <Ganesh.Sittampalam@comlab.ox.ac.uk>
Subject: Re: [abc] nice paper! :)

Here're my comments - I'm just sending them to you, so pass them on to
whoever is in charge of editing it. Obviously feel free to ignore any of
them - a lot of them are fairly subjective. Prefix them all with 'IMHO'

Abstract: "Type checking" is used once with a space and once without - I'm
not sure which is correct

"Its frontend is .. itself a modular extension of java" - I don't
understand what this means

".. a number of small, yet nontrivial examples" - I'd leave out the comma

Section 1: "In first instance" should be "In the first instance"

"Such interpreters are useful in defining the semantics and in explaining
the compilation strategy" add "...of new language features"

"Challenges" section: "A more involved extension are" should be "a more
involved extension is"

"parameters evaluated at weave-time" - this seems like a very
implementation specific term/piece of jargon - would 'compile-time' do
instead?

Next page: "...restrict the visibility of join points to those that are
explicit in its interface" - I couldn't work out what the "it" is here

"... as well as the mathers for join point shadows and type patterns" -
this sentence is quite unclear, could it be made rearranged?

"...ranging from simple variations in syntax to escape analysis in the
presence of advice" - I'm not sure what this means

Design goals - simplicity - "it must be relatively simple develop" - add
'to' before develop

proportionality - should be "There should not be a large overhead to
specify an extension"

analysability - seems like a very strange choice of word (if it is a
word...) - the first 3 goals are properties of the compiler, the last
seems to refer to the compiler's input. Could it be changed to "power" or
something, eg "the compiler should have the power to easily perform
optimisations and analyses"

next column: "important to design abc so that both are used as is" - both
what?

Architecture section: "soot provides a convenient intermediate
representation on which" - replace with " ..representation with which"

"Polyglot can read class files to process library code." This is a very
short sentence, it could be combined with the following sentence

"Polyglot [23] is a front-end for Java intended.." should this be
"front-end of Java compilers"?

Java To Jimple should probably be italicised

"modifications of the AspectJ grammar" should be "modifications to the
AspectJ grammar"

Section 3.0 - replace 'make' with 'create' and 'too much' with 'excessive'

3.1: "while in pointcuts, it is part of a name pattern" - get rid of the
comma

"The general pattern we use is that we" - replace "that we" with "to"

"count the nesting level, too" - remove comma

3.2: "At the minimum" might be better as "As a minimum"

When referring to the ideas in [6], a brief description would be useful
for those of us too lazy to go off and read it

3.3: italicise _return_ statements "..at each point where it is woven in"
- remove 'in' Section 3.4 "named classname pattern expressions" - this is
about the 3rd different phrase used to describe this extension, it would
be good to settle on one.

5.5: "This method, matchesAt" should have '()' at the end for consistency
(twice)

Section 5 generally - when referring to types of pointcut, eg "throw
pointcuts", sometimes the type is in bold, sometimes it's not

5.7 "which is to directly generating code" should be "which is to directly
generate code"

bullet point "Declaring type - class that the join point occurs within"
should be "class within which the join point occurs"

5.7 - should "HashMap" and "IntHashTable" refer to the same class?

section 6 - mention of XQuery - I don't know what XQuery is, could a
reference be provided?

Hope at least some of these are useful!

Chris

In message <Pine.LNX.4.44.0409290037180.25587-102000@urchin.earth.li> Ganesh
Sittampalam <Ganesh.Sittampalam@comlab.ox.ac.uk> writes:
> Attached as .ps and .pdf
>
> Thanks!
>
> Ganesh
>
> On Wed, 29 Sep 2004, Chris Allan wrote:
>
> >
> > I can probably be of help with proofreading the paper - I spent a few of
> > my teenage years proofreading academic papers/books for various people,
> > so if nothing else can pick out spelling mistakes etc.
> >
> > It looks like I may have to spend most of tomorrow on a school
> > visit/Access event, but if someone could email me a recent copy of the
> > paper asap I'd be more than happy to cast a "fairly technical but not
> > too involved" eye over it.
> >
> > Chris
> >
> > Oege de Moor wrote:
> > >
> > > On Tue, 28 Sep 2004, Prof. Laurie HENDREN wrote:
> > >
> > >
> > >>I have read through the paper and made only very minor changes.
> > >>I am very impressed with the paper. It is very professionaly done,
> > >>with lots of related work (thanks Oege for all your research there!...
> > >>I think it helps it be an AOSD paper rather than just a compiler paper)
> > >
> > >
> > > Erm. There are errors in that, like the fact that I missed the
> > > public distribution of josh. Thanks to Ondrej for noting that,
> > > and a little hint to everyone else to pick a random reference
> > > and check that what I said is actually true!
> > >
> > >
> > >>I don't see any major changes left to be made. Someone needs to
> > >>design our "abc technical report latex format" so we can make
> > >>the technical report version as soon as we submit the paper and
> > >>then put it on the aspectbench.org web site and send copies to
> > >>our friends. I would love to do it, but I seem to have a queue
> > >>of "other papers" I am supposed to be working on.
> > >
> > >
> > > right, that would be nice.
> > >
> > >
> > >>I guess we also need an official "last reader" who goes over
> > >>it for a last time looking for typos. I am afraid I'm not so good
> > >>at that any more .... I seem to have gained speed at the expense
> > >>of accuracy ....
> > >
> > >
> > > Damien is doing a pass tonight.
> > >
> > > Personally I think it is worthwhile to spend tomorrow on making
> > > a few more improvements:
> > > a) check references (as suggested above, but also just the
> > > details of publication venue etc)
> > > b) look for further typos, obscurities etc.
> > > c) run the whole thing through a spell checker
> > >
> > > A good technique (and I'm not joking here) is to read the
> > > paper backwards at this stage. If you read it forwards, it
> > > all goes "yeah, seen that before, obvious..." and you read what
> > > you think, not what's written.
> > >
> > >
> > >>Anyway, a job well done. I hope the "young guys" found this an
> > >>interesting experience. Now we have to shift our focus to our
> > >>release (I go to CASCON next Wednesday, and would love announce
> > >>the real release then...) and we also have to work on writing the
> > >>CC paper and doing the analysis stuff for the PLDI paper.
> > >
> > >
> > > I'm sorry, but I'm firmly of the opinion we're not ready for
> > > a release. Quite understandably, after the IBM visit we have
> > > slowed down a lot. Before we release, we should
> > >
> > > a) compile abc itself (so it is really possible to use aspects
> > > for extension if people want to do that - it's not just
> > > a fun meta-circular thing).
> > >
> > > b) compile atrack, or at least fix all the problems that
> > > Ondrej has found
> > >
> > > c) pepper the source with javadoc. It is very sparse at
> > > the moment, and I do not believe the source is of
> > > use outside our team in its present form.
> > >
> > > While I'm really happy with how far we've got, it is a fact
> > > that, even for a simple program like my ants viewer, there
> > > were several things that needed fixing in abc before it could
> > > be compiled. No pathological corner cases: a real program.
> > > We have to have more confidence that abc won't break on
> > > the first sizable example people try.
> > >
> > > Now of course we *could* race to bring out a release by CASCON,
> > > and if we're lucky we'll get real users and umpteen bug reports
> > > to fix that same week. Now we have to ask ourselves whether
> > > that is the best use of a team that is going to drop in manpower
> > > a lot as of next week, when term starts and several of the
> > > Oxford gang have to go back (at least part-time :-))
> > > to being undergrads.
> > >
> > > I think it is far more productive to get on quietly with
> > > a-c) above, the CC paper, and most importantly with re-weaving.
> > > That was the crucial idea that started all this in January;
> > > it got lost in the development fever but fortunately Ondrej
> > > insisted on getting back to it. We have to get it ready for
> > > PLDI. The realisation of re-weaving will underlie lots of our
> > > future plans, and it will be a big boost to our chances of
> > > continuing the project if we have demonstrated it works. I
> > > don't think a release would have the same impact.
> > >
> > > Sorry for a long email. Obviously it's important we make the
> > > right strategic step now, with the very limited resources we've
> > > got.
> > >
> > > -Oege
> > >
> > >
> > >
> >
> >
Received on Wed Sep 29 13:27:45 2004