[MLton] Selectors in -show-def-use output

[Matthew Fluet]

> Working on the def-use-mode (http://mlton.org/EmacsDefUseMode) I noticed that the
> def-use info includes selectors.  For example, the following (in -show-def-use
> generated output) refers to a selector (#1):
> 
> variable x mltonlib/com/ssh/extended-basis/unstable/detail/list.sml 18.20
>     mltonlib/com/ssh/extended-basis/unstable/detail/list.sml 18.20
> 
> Is there a reason why selectors are also included in the def-use output or is it
> just an oversight?  I'd like to filter them out.
> 
> BTW, I assume (haven't checked it from the MLton source, yet) these spurious selector
> variables are related to the implementation of selectors.  

The Definition specifies that selectors are just a derived form in which:
   #lab
expands to
   fn {lab = vid, ...} => vid
for some fresh value identifier vid.

On the other hand, for the purposes of def-use information, we don't 
follow all of the derived forms.  For example, the function value binding:
     <op>vid apat11 ... apat1n<:ty> = exp1
   | <op>vid apat21 ... apat2n<:ty> = exp2
   | ...
   | <op>vid apatm1 ... apatmn<:ty> = expm
is supposed to expand to
   <op>vid = fn vid1 => ... => fn vidn =>
   case (vid1, ..., vidn) of
     (apat11, ..., apat1n) => exp1<:ty>
   | (apat21, ..., apat2n) => exp2<:ty>
   | ...
   | (apatm1, ..., apatmn) => expm<:ty>
for fresh and distinct vid1, ..., vidn.

But the def-use information for such a form doesn't include the fresh 
and distinct vid1, ..., vidn.

So, it is probably not the right choice to expose the dummy variable in 
the def-use information.  Somewhere in elaborate-core.fun is probably 
the right place to fix this.