shrinker checked in

[Matthew Fluet]

> > >   - Added mayRaise: bool to functions to record whether or not a function may
> > >     raise.
> > 
> > Would it be worth replacing mayRaise with raises : Type.t vector option to
> > match returns?  I know that this vector should be identical in all
> > functions, but it would make things a little more uniform.
> 
> No objection here.  I can even imagine an optimization that represents
> exceptions differently in different parts of the program.

That's sort of what I had in mind; I could imagine partitioning the exn
datatype into classes dependent upon what could be raised by different
functions.  You probably pay a little in converting exceptions in
different classes (like Overflow), but the benefit might be better passing
of exception arguments. 

> It's not what the callee can do.  I agree that our current convention
> is that the callee preserves the exception stack, essentially treating
> the global (per thread) exception stack pointer as a callee save
> register.  The problem is that None means that the *caller* can leave
> the exception stack in *any* state that it likes.  But that means that
> when the callee returns (as it is allowed to do with a Caller cont),
> the exception stack will be in that same *any* state.  But the
> continuation may refer to the exception stack.  Hence, Caller/None
> doesn't make sense -- it only makes sense to have Caller/Caller,
> i.e. Tail.

I think I get it now.