[MLton-user] Lack of information with -const 'Exn.keepHistory true'

[Matthew Fluet]

> The previous version we used (20030716) used a different mechanism to handle
> the option '-exn-history true'. Though it was not perfect, we could manage
> to hack our code and get more information by adding a bunch of "handle x =>
> raise x" constructs in our code.
> 
> Unfortunately, this does not change anything with the new mechanism. 
> 
> Do you think there would be a similar construct we could use in order to
> achieve the same result with the new mechanism ? (then we may find a
> solution to apply it thanks to the defunctorizer we use).

No elegant solution comes to mind.  There are a variety of inelegant 
solutions:
1) Use a construct like:
      handle x => (print ("Raising exception "
                          ^ (exnName x)
                          ^ " through foo.sml:42\n")
                   ; raise x)
    That would have the dynamic effect of displaying the exn stack.
2) Use a construct like:
      fun f x = ...
      fun f' n x = if n = 0 then f x else f' (n-1) x
      val f = f' 1
    I think that this would have the effect of putting extra f' frames on
    the stack; there is, of course, a slight runtime penalty for this.

It is probably worth investigating why we aren't getting as accurate 
call stack information as we would like.  Indeed, I'd really like to 
have an option like '-profile-val {false|true}', which would push and 
pop profiling information for the evaluation of val bindings, especially 
val bindings at the top-level.  For example, with code like the following:

   exception Uninitialized
   val r : int option ref = ref NONE

   val r = fn () => (case !r of
                        NONE => raise Uninitialized
                      | SOME i => i)

   fun y () = (r ()) + 2

   val z = (r ()) + 1

using "-const 'Exn.keepHistory true' -profile-raise true" yields no 
information.  I thought that the behavior of "-profile-raise true" would 
have always included the "raise" expression in the call stack; but, even 
with that, the more useful information is that the exception was raised 
during the evaluation of the top-level 'val z =' binding.