comments

[Suresh Jagannathan]

Here are some comments based on a first read; I'm sure that
the version I grabbed (yesterday morning) is out-of-date, so
of my comments may have already been incorporated.

Section 1 and 3.2

1. I think the relationship between SSA and CPS is well-known, and
doesn't require a separate section esp. since there's no specific
experimental data on optimizations used on the contified program
that is SSA-based described in the paper.

2. It's not clear many people are aware of proc/cont lambdas in
Richards's work (actually, I think it's proc/jump lambdas if
I'm not mistaken).  I'd dop the reference.

3. I agree with Henry's comments on the example -- there are no
non-tails in CPS, so you need to be careful about how you express
what's going on there.

3. "to contify" is not a verb; "contify" is.

Section 2. 

I would reorder the description of MLton's structure to put
flow-analysis before closure conversion (since that's how
it's structured logically in the implementation).

2. I think the use of parens for returns is very confusing;
I'd drop it.

3. Rather than saying "Some readers may be confused", I'd
rewrite to say "The reader might observe that the CPS ...".

3. I think it's important to highlight that wrt control-flow,
contification simply turns function calls to jumps in the
context of this IL.

4. I was a bit confused by the loop example, in particular 
because contification appears superficially to have the
same effect as inlining here -- wouldn't we get the same
code structure (after simplification) as you would if
you inlined loop within sum?  Also, I wouldn't use the same
variable name for the accumulator (in loop) and the 
function sum.  

5. I think the quote from Richard's paper is unnecessary
esp. as it refers to "proc" expressions which are not 
properly explained.  Given that Richard's paper is not 
well-cited, I would punt the expanded quote, and summarize
the reference.

6. I'd punt Section 3.2 as it stands, or (a) elaborate
to justify why it's where it is in the paper, or (b)
move it closer to the intro.

Section 4.

1.  In the table describing A(f), can I replace "f always
returns to continuation k" with "f only returns to
continuation k"; the former sentence allows f to return
to different continuations all of whom may eventually
return to k, whereas the latter prohibits this.  Which 
meaning did you intend?  In any case, I think you might
consider elaborating a bit more here since this section forms
the crux of the paper.

2.  "all safe analyses label all and only the unreachable
functions"  -- I don't understand this.

3. "In order for the transformation to for" -- fix.

4. "the an analysis"

5. In the code fragment with function fm, the continuation
is capitalized (K).

7. "Another way to think of the safety" --> "Another way to
think of safety"

8. The continuation K in the program fragment describing 
maximal analyses is capitalized.

9. I didn't follow your description of maximal analysis.
Analysis A1 claims that g always returns to f, whereas
A2 claims g always returns to K -- surely, this distinction
would lead to different optimization opportunities.  If
not, I think it would be worthwhile explaining why not.
(Perhaps because the implementation computes a least
fixed-point over reachable paths, or something along 
those lines.)

10. I find the description in Section 4.2 describing 
tail calls confusing; there's a matrix of four cases
that are blurred together.  I think it would be good
to expand or clarify.

Section 5.

I'm still going through it, although I found it well-written
on my first read.

Section 6. 

Fine, but it would be nice to have some conclusion about
what the numbers mean; something along the lines of 
a "dominator-based analysis is the preferred contification
strategy for ML-like languages written in a functional
style" etc.

I'll try to have some comments on Section 5 later today.

--Suresh