Re: [abc] comments from Chris

On Wed, 29 Sep 2004, Ganesh Sittampalam wrote:

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

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

Its frontend is built, using the Polyglot framework, as a modular
extension of the Java language.

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

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

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

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

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

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

the class' interface
> 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

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

making advanced analyses (such as escape analysis) take into account
the effects of advice
> "...ranging from simple variations in syntax to escape analysis in the
> presence of advice" - I'm not sure what this means

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

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

analyisis capability
> 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"

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

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

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

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

right
> Java To Jimple should probably be italicised

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

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

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

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

change to also
> "count the nesting level, too" - remove comma
>

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

remove (as suggested in)
> 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

bold
named class pattern expressions
> 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.

(..) (also in lexer)
> 5.5: "This method, matchesAt" should have '()' at the end for consistency
> (twice)

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

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

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

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

the XML query language XQuery
> 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 14:45:41 2004