val _ = () and exception optimization in MLton

[Stephen Weeks]

> Isn't this going to weaken the utility of the optimization 
> seriously?  Other than for fairly trivial expressions or
> loops containing fairly trivial expressions, I don't see
> how this optimization would get enabled since I would
> expect almost any interesting expression to have a non-tail
> call somewhere in its dynamic scope.

You're thinking too close to source programs.  I agree that you will almost
never see this in source programs.  However, after lots of optimization, and
inlining, who knows.  Remember that one of the ideas of MLton is to let the
programmer write abstract code without worrying about paying for it.  One kind
of abstraction that I often use in my code is to define a function that takes a
thunk, does something, runs the thunk while handling exceptions to clean up.
One can't know when writing such an abstraction what will be in the body of the
try.  Sometimes, the try will be a simple expression or a loop, and in that
case, I don't want to pay for the handler.

And don't forget the important case of when all of the raises are turned to
jumps and this optimization then removes the HandlerPush, possibly letting us
even inling the handler.