Re: [abc] oopsla paper

Incorporated comments into section 6:

>p.12, left column. Mention that the alphabet of the automaton is the
>set of symbols, and define skip before introducing the automaton of
>Figure 7
>
>
Added a few sentences to that effect:

"The alphabet of this automaton consists of exactly the declared
tracematch symbols, with one special symbol which we call \emph{skip}.
Transitions labelled with this symbol are triggered exactly under the
circumstances that prevent all \emph{declared} symbols from matching. It
is also the only source of negative bindings. For a more detailed
discussion of \emph{skip} and its semantics, see \cite{oopsla05abc}."

>p.12, right column. "For this reason each tracematch NFA is converted
>to a minimal DFA during compilation..." This is a tricky point because
>there are several automata at different stages of the constructions,
>and some of them are definitely NFAs (because of the skip loop
>requirement). Am I right in thinking that the _pattern_ automaton is
>converted to a minimal DFA, not the actual automaton matched at
>runtime? Also the minimal DFA may be larger than a minimal NFA but (I
>think) is easier to compute.
>
>
Yes, you are quite right. Changed "each tracematch NFA" to "the NFA of
each tracematch pattern", left remainder unchanged.

>Sections 6.2 and 6.3 seem a little bit abstract as they stand. The
>second paragraph could briefly remind the reader (from 6.1) that each
>state is labelled with a formula built from equalities and
>inequalities, and /\ and \/. These can be represented in DNF, so we
>need a good representation of Disjuncts, ie conjunctions of equalities
>and inequalities. A constraint is just a disjunction (set) of these.
>Then as before.
>
>
Rephrased that paragraph a bit. Recapped that constraints are
(in)equalities with \/ and /\.

>I'm not quite sure how to make 6.3 more concrete though. Is it
>possible to give a partial signature of Disjunct (specialised) and
>Constraint in a figure? Or just the operations on them, informally?
>
>
Hm. It's hard to give something more concrete without getting bogged
down with the details, that's why I mentioned "methods that record new
bindings" and "methods that perform logical disjunction" at a very
general level, to give an intuition. Any suggestions on how to make that
more accessible would be welcome.

>2nd and 3rd paragraph: so that the reader doesn't get scared when we
>start talking about analyses, change "the brunt of the analyses happen
>on the automaton..." to saying that it be should stressed again that
>no expensive whole-program analysis is required, and that this is in
>fact a local analysis of the tracematch automaton itself.
>
>
Good point; done.

>After the "StrongRefs / WeakRefs / CollectableWeakRefs" list: I think
>the paragraph detailing when we give warnings should be moved to
>_after_ describing when space leaks can occur (next 3 paras). This
>seems more logical:
> 1. How do we avoid leaks?
> 2. What cases are left? Give a warning for these.
>
>
Again, good point. Done.

>Typo. p.15 column 2 "States are, in general [...] , if possible.." Two periods
>
>
Fixed.
Received on Fri Mar 17 15:18:59 2006