exceptions

[Matthew Fluet]

> > Are we eventually planning on moving to the point where the SSA IL doesn't
> > need HandlerPush and HandlerPop, and implement handlers works entirely
> > from the information in  Transfer.Call {return, ...}?
> 
> Yes.  The only reason HandlerPush and Pop are there is for the
> exceptions paper, where we will want to compare our fine new
> strategies for installing handlers against a strategy based on the
> handle expressions in the source program.

That's what I thought; just wanted to make sure it was on the horizon.

> > But, we can get into situations like
> >  
> >  fun f () = ... raise Overflow ...
> >  fun g () = ... raise Overflow ...
> >  fun h () = ... ( ... f () ... g () ...) handle _ => exp1 ... 
> >  fun i () = ... ( ... f () ... ) handle Overflow => exp2 ...
> >  fun main () = ... h () ... i () ...
> 
> The right fix for your problems is to use equality constraints instead
> of less-than constraints in the analysis.  That way, we determine that
> f must raise because of i, and that therefore the handle in h must
> handle, and therefore that g must raise.

O.k.  I can fake that by making the flow go both ways at raises and
handlers.


Anyways, I'm going to out of town through Saturday, so I won't be checking
any of this stuff in until after that.  I've got no objections to killing
off CPS if all of the benchmarks and regressions came out alright.