val _ = () and exception optimization in MLton

[Stephen Weeks]

> I  guess  that  I  was  assuming that it was already true that if the handled
> expression made no procedure calls then the list  of  active  handlers  would
> never be changed.

That hadn't been done yet.
 
> Still,  I  really  am  not  convinced  that this optimization is going to buy
> anything.  The example you give is misleading because the handler handles all
> exceptions.

That doesn't matter at all.  In some sense, all handlers handle all exceptions
(of course, some may re-raise it).

> Also note that the transformation you have used can really hurt
> the common case where no  exception  is  raised  (because  now  the  cost  of
> establishing a handler is unbounded).  I.e., as I understand it code like
> 
>     let fun inner n =
>                if n = 0
>                   then ()
>                   else inner (n - 1)
>         fun outer n =
>                if n = 0
>                   then ()
>                   else (inner n;
>                         outer (n - 1))
>     in outer 1000 handle _ => ()
>     end
> 
> Will  put  up  and tear down the handler 10^6 times, while the old code would
> have  done  it  once.

No.  It would be installed once, for the outer 1000 call.  I believe the
transformation can only increase the number of handlers installed by a constant
factor, dependent on the program (but not the input).  I believe that with the
other (as yet unimplemented) optimization I mentioned, there will be no more
handlers pushed/popped than the old MLton.

> (Note,  this  also  shows  another  reason  why   the
> optimization  doesn't  buy  much.   Even  arithmetic can raise an exception.)

Arithmetic can't raise an exception :-)