comments

Stephen Weeks MLton@sourcelight.com
Wed, 14 Mar 2001 12:25:23 -0800 (PST)


Here's my response to some of this morning's flurry of email.  I've put the
remaining unresolved questions from the mail at the top of the todo file.  The
latest snapshot is at http://www.star-lab.com/sweeks/01-icfp.tgz.  I am off to
lunch.  Matthew, you have the token to everything.

> It also is a  bit  strange  that  although  procedures  can  return  multiple
> results, primitives cannot.

Oh well.  I agree, but we haven't needed it yet, and I don't think it matters.

> I don't know what to do about the meaning function; change it to some
> Greek letter? 

I changed it to \delta.

> Why not state lemma 1 using the negation of R(f).  I.e.,
>         If A is a safe analysis, then not R(f) iff A(f) = Uncalled.
> Then it is obvious that is just strengthening condition *-1.  I can't  figure
> if  a  symbol  for unreached (instead of R for reached) would be better every
> where, but it certainly would be better up through here.

I like R for reached.  It is used positively in enough places.  As to the change 
in lemma 1, I like it.

> > The sentence in the first paragraph after the proof to lemma 1
> > is clearly busted.
> 
> Fixed.

> > 2. I think the use of parens for returns is very confusing;
> > I'd drop it.
> 
> everything uses ()'s for returns now, but I don't have a problem dropping
> them.

OK.  I dropped them.

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

Loop is recursive.  What do you mean by inlining it?  Should we
mention something to avoid this confusion?