[MLton] Non-exhaustive exn fn match

[Stephen Weeks]

> Sorry, I meant to refer to "Type-Specialized Serialization with
> Sharing" (http://www1.itu.dk/sw5450.asp).

BTW, we have a convenient and concise way to refer to shared papers
via the wiki (e.g mlton.org/References#Elsman04).  If a paper we talk
about isn't up there, it should be.

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

That code also has a space leak.  The problem is explained (and fixed)
on mlton.org/UniversalType.  As to thread unsafety, it seems easy
enough to wrap the projection function in a MLton.Thread.atomically to
achieve thread safety.

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

Sounds good to me.

> How does "warnExnMatch" sound for the annotation name?

Great.

Vesa, do you have any interest in implementing warnExnMatch?  As
Matthew said, it should be easy to implement, and would give a nice
intro to some of the front end.  We'd be happy to walk you through it.
As an additional benefit, some of the explanations might make it onto
the wiki to grow our documentation of compiler internals.

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

Sounds good.  I would also have allowFFI enable _address.

As to the fine grained annotations, they may have looked good at the
time, but as we add more FFI extensions, I don't really see the point.
benefit of them.  I'd be just as happy to have only allowFFI, to
deprecate allow{Export,Import}, and to not add allow{Address,Symbol}.