[MLton] Non-exhaustive exn fn match

[Matthew Fluet]

> 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.
> 
> 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.

That is somewhat unfortunate.  My first response was to try to re-use the 
handle expression, whose match does not require an exhaustiveness warning.  
But,

  fn () =>
     expect (fn () => ...,
             fn e => raise e handle Fix => ())

is really no better.

> 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.

That seems like a fair suggestion and it would be quite easy to implement.  
I also think it fits well with the MLton philosophy on SML
extensions/deviations, noting that the default behavior would be to follow
the Definition, such an annotation does not alter the semantics of either
the statics or dynamics, nor would it break source compatibility with any
other compiler.

How does "warnExnMatch" sound for the annotation name?


While we're on the subject of MLBasis annotations, I have two minor 
improvements to propose.

1) Add an "allowFFI {false|true}" annotation, which would simultaneously 
   affect "allowImport", "allowExport", and "allowSymbol" (corresponding 
   to the new _symbol primitive).  The fine-grained control is nice, but 
   as we argued with _symbol, as soon as you want one, you're likely to 
   want the others.

2) Extend the general syntax of annotations to
     ann "[compiler:]ann [opt ...]" in basexp end

   The idea is that a compiler should silently ignore annotations marked 
   for a different compiler, while it may issue a warning for unmarked 
   annotations that it doesn't understand.