20000712 bug report

[Stephen Weeks]

> Included are a couple of programs that I made as small as I could
> (though I'm sure they could be smaller) that display some undesirable
> behaviour :-
...
>   amidala$ mlton gen1.sml
>   gen1.sml:17.0-17.0 Error: unhandled exception in parser
>   mlton: bug: compilation aborted: parse reported errors

If I feed gen1.sml into SML/NJ, I get

/tmp/sml.tmp.cL1r2P:17.13 Error: syntax error: inserting  EQUALOP

>   amidala$ mlton gen2.sml
>   mlton: bug: unify Con
>   amidala$ 
> 
> There might well be a problem unifying a constructor but a line number
> would be nice :-)

If I feed gen2.sml into SML/NJ, I get

/tmp/sml.tmp.TOJsxr:19.19-19.47 Error: operator and operand don't agree [tycon mismatch]
  operator domain: string list
  operand:         unit -> string list
  in expression:
    args CommandLine.arguments


Hopefully, both of those error messages make sense.  To quote from the
"drawbacks" section of the MLton User Guide -- it is strongly recommend that you
type check your programs with another SML compiler before compiling them with
MLton.  Actually, it should probably be stated more strongly.  I would recommend
always running your program through another SML compiler to see if it type
checks before using MLton.  My usual mode of operation is to try SML/NJ, but I
keep the ML Kit and Moscow ML around for type checking as well.  I only use
MLton to generate the final executable after type checking has succeeded.  Hope
this helps.