[MLton] Non-exhaustive exn fn match

[Matthew Fluet]

> > 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.
> 
> I'm not sure about this one. For (mostly) semantics preserving annotations
> (e.g. enabling/disabling warnings) I would probably prefer to get no
> warnings on compilers that do not happen to support the annotations. For
> semantics modifying annotations (e.g. enabling extensions) I would probably
> prefer to get a warning or even an error (better to get a single specific
> error than dozens of errors for a program using an extension). 

One problem, as I see it, is that each compiler would then need to know 
all of the annotations supported by other compilers, and need to know 
which were semantics preserving and which were not.

> So, one
> alternative might be to allow an annotation to be annotated as "optional"
> (default) or "required" (to get a warning or error). This way the annotations
> would not be dependent upon particular compilers.

Even with this, it is now the user who needs to know whether or not a
particular annotation is semantics preserving.  Granted, it would be most
desirable for users to know whether or not (or how far) they are straying
from the Definition, but there are some subtleties.  For example, 
"sequenceUnit true" has a fairly straightforward explaination, but subtle 
effects, such as possibly changing the principal signatures of modules.

The motivation for the [compiler:] mark is to ensure that the MLBasis
system is open enough that other compilers could add/modify specific
annotations without needing to coordinate with other implementations.  It
is certainly in everyone's interest to agree on names and semantics for
common/useful annotations.  But I imagine that most other annotations are 
compiler specific -- how do you turn on/off FFI interfaces, specifying 
inlining threshholds, etc.  These are the sorts of things that only make 
sense in one compiler, and never in another.  They are also things that 
are generally semantics preserving (e.g., optimization flags) or so 
semantics destroying (e.g., FFI) that you'll need to have specific 
implementations for different compilers.

In light of the last point, some means of conditional compilation in 
MLBasis files would still be desirable, but needs some design thought.  
Interestingly, MLBasis path variables give rise to a poor-man's 
conditional compilation system, in the sense that if we were to provide 
bindings for path variables corresponding to various system parameters 
(e.g., COMPILER, OS, ARCH, etc.) then one might choose to write:

foo.mlb:
  foo-ffi/$(COMPILER)/$(OS)-$(ARCH).mlb
  foo.sig
  foo.sml

for a binding to a C-library, compensating for differences in compilers 
and target system.  (It may very well turn out that you have

linux-x86.mlb, freebsd-x86.mlb, ...:
  unix-x86.mlb

where unix-x86.mlb has the "real" work, since all unices often look the 
same at this level.)