Re: [abc] nice paper! :)

I just made a complete pass through the paper. I agree that most of it
is getting very polished. However, I think there are certain specific
small sections which still need to be reworked, particularly in section 3.

For minor changes (mostly grammar and spelling), I just made them and
checked in. Major changes I discuss below.

Section 3.1 talks about many details of the lexer which are not closely
related to extensibility. When it does talk about extensibility, it
focuses on ways in which it is not extensible, rather than ways in which
it is extensible. Then, for the parser, which is nicely extnesible, it
gives very little detail. I actually think that the level of detail for
the parser is sufficient, but that the lexer should be described with a
similar level of detail. In particular, our main points (I think) are:

- the lexer is extensible in that you can change the set of keywords,
and define new actions for new keywords
- you need to be aware that the set of keywords is different in
different parts of the language [this is our design decision; in this
paper, we don't need three paragraphs to justify it, just a single
sentence to state it. The three paragraphs will be good for the CC
paper.]
- if you need to extend it more than just by adding keywords, you can
always replace it with a new one.

It is not relevant that the Polyglot lexer is not extensible. Yes,
Pavel did very nice work in turning the non-extensible lexer into an
extensible one, but this is not a work report; the readers will be using
abc, not Polyglot, so they don't care about shortcomings of Polyglot's
lexer.

Section 3.3 launches directly into binding constructs, leaving the
reader very confused. What are the main points in 3.3? How should it be
organized? Currently it is not organized at all. I wonder whether the
first and second paragraph should be switched. But, since I have no clue
of what we're trying to say here (even after reading the section several
times), I'm not sure. If I can't figure out what we want to say,
neither will the reviewers.

At the end of Section 3.4, two specific interfaces are mentioned, with
nothing to say what methods must be implemented to implement them. I
think what we're trying to say here is that in abc, we added a bunch of
passes, and new nodes must provide an implementation of those passes,
either by inheriting an implementation from a superclass node, or by
containing an implementation of the method. If we want to be more
specific, we can list the set of passes that need to be implemented, but
specifying the two interfaces tells the reader who is not intimately
familiar with the code very little.

In Section 3.6, I don't see how anything but the last two paragraphs are
relevant to this paper. Everything else should be moved to the CC paper.
Remember that Section 3 is just supposed to give a basic overview of
what can be extended.

An off-topic aside inspired by Section 3.7: It says that there are few
proposals of truly novel types of advice. Here's one: it seems quite
common to disallow around advice because it would be hard to decide what
to do if the advice didn't call proceed or called it multiple times. How
about a before-after advice, which does not have proceed, but has two
blocks, woven before and after, but each block can see the other block's
local variables. I imagine that many uses of around are not to change the
proceed call, but simply to pass some data between before and after advice.

In section 3.8, the last two paragraphs again have nothing to do with
extensibility, but will be a major part of our PLDI paper. Let's save
them for PLDI.

We should keep in mind that although we like to write abc, the Polyglot
people like the capital P. I fixed all current occurrences, but please
keep it in mind when writing new text.

Ondrej
Received on Tue Sep 28 23:32:12 2004