[MLton] upcoming release

[Matthew Fluet]

> Quoting Matthew Fluet <fluet@cs.cornell.edu>:
> > > It has been quite a while since our last release, so I would like to
> > > do a new one.  There aren't any huge new features, but we have
> > > accumulated a number of bugfixes, as well as some small improvements:
> [...]
> >  * warnExnMatch annotation
> 
> I was hoping to submit a patch to implement
> 
>   ignoreNonexhaustiveExnMatch {false|true}  <-- seems better this way
>   nonexhaustiveMatch {warn|error|ignore}

Another alternative might be

  nonexhaustiveExnMatch {default|ignore}

where "default" means to follow the nonexhaustiveMatch annotation.

> before the next release, but it now seems I will be too busy in the next
> two (or three) weeks to complete the implementation. I could probably
> find time to prepare a patch to implement
> 
>   ignoreNonexhaustiveExnMatch {true|false}
>   nonexhaustiveMatch {warn|error|ignore}
>   redundantMatch {warn|error|ignore}
> 
> as I've had them almost done (only backwards compatibility with warnExnMatch
> is missing) for a few days already.

You could probably skip compatibility with warnExnMatch, since it has 
never appeared in a public release.

> I kind of like it that after replacing "warnMatch false" with just
> "nonexhaustiveMatch ignore" none of the libraries/tools that come with
> MLton (seem to) produce warnings. IOW, "redundantMatch ignore" is not
> needed.

All of the libraries in the MLton source should have "warnMatch true", and 
the silence of compilation indicates that there are no nonexhaustive or 
redundant matches in the sources.  We would like to preserve that in 
future code evolution, so we would replace "warnMatch true" with 
"nonexhaustiveMatch warn, redundantMatch warn".

> Is it worth preparing the patch before the next release?

I'd prefer not to delay the release waiting for more features.  On the 
other hand, I'd rather not release with warnExnMatch only to remove it in 
the next release.

If you can prepare the patch, send it along and we can probably get 
sequenceNonUnit to also work with the ignore|warn|error annotation.  I'm 
still in favor of skipping ignore|warn|error with regards to 
unusedIdentifier in this round.