[MLton] Non-exhaustive exn fn match

[Vesa Karvonen]

Looking at the Definition (page 28) it says that "In the context fn match,
the match must also be exhaustive [...]" and "The compiler must give
warning on violation [...]". I totally agree about the general case (a
non-exhaustive match of a datatype should give a warning), but it seems
that in the specific case when the type of the pattern is `exn', it might
make sense to not to require a warning.

Looking through my code, I can see multiple places where I use a fn match
of the form

  fn SomeExn => ... | _ => raise Match

just to silence the compiler(s). For example, I have a function

  val expect : (unit -> 'a) * (exn -> unit) -> unit
  fun expect (f, m) = try (f, throw Match, m)

(try = try-in-unless, throw = fn exn => fn _ => raise exn)

for conveniently specifying negative unit tests. For example, here is how
I would like to write a test for my SRFI-45 conversion:

  fn () =>
     expect (fn () => fix (fn invalid => (force invalid ; eager ())),
             fn Fix => ())

(`fix' is a fixed point operator for promises and `Fix' is the exception
thrown in case it fails to tie the knot.) Unfortunately the above (and all
similar negative tests) must be mutilated to

  fn () =>
     expect (fn () => fix (fn invalid => (force invalid ; eager ())),
             fn Fix => () | _ => raise Match)

to silence the compiler.

Another case where I use `| _ => raise Match' just to silence the compiler,
occures inside my implementation of a universal/dynamic type with equality
using exceptions as suggested in Type Specialization with Sharing by
Martin Elsman. (BTW, the use of ref cells to implement a universal type is
a mistake, IMO, because the shared ref cell makes the technique thread
unsafe.)

So, I was wondering if it might sense to provide a MLBasis annotation for
turning the warning off in the case a non-exhaustive fn match is due to an
exn pattern. I wouldn't want to turn off all non-exhaustive match warnings.

-Vesa Karvonen