[MLton] cvs commit: added flags -show-def-use, -warn-unused

[Stephen Weeks]

> In the following:
> 
> fun app f i [] = []
>   | app f i (x::xs) = (f(i,x); app f (i + 1) xs)
> 
> mlton -warn-unused true  reports that f and i in the first case are
> unused.  I guess that is technically true, but I would never write the
> function as:
> 
> fun app _ _ [] = []
>   | app f i (x::xs) = (f(i,x); app f (i + 1) xs)
> 
> I don't know if it is possible to merge the def-use information for
> function arguments from different cases, but that would seem to be one
> source of spurious errors.  In such a function definition, I would care to
> know that an argument was unused in all cases, but not that an argument
> was unused in an individual case.

I'm with Henry on this one.  Further, I think it is a bad idiom that
makes you repeat things (both the repeated "app" and the repeated args
"f" and "i") that could later change and get out of sync.  I also
think the second form with the _ _ is better SML because it makes
information available to the reader -- that the arguments are unused.
Obviously with the small expression it's not much information in this
case, but in general it could be helpful, and I can't see how it
hurts.

So, I like the warning in this case.

> Another related idiom would be to always name the components of a
> datatype, even if they are unused:
> 
> fun head (x::xs) = x
>   | head _ => raise Fail "head"
> 
> I'm not sure that there would be many non-spurious warnings here.

I think this is sloppy programming as well, and it would be preferable
to use _ instead of binding an unused variable.

So, I like the warning in this case as well.