## 14 Bugs

### 14.1 Reporting a bug

To report a bug, please send mail to `MLton@mlton.org`. Please include the complete SML program that caused the problem and a log of a compile of the program with `-verbose 2`.

### 14.2 Unresolved bugs

This section lists the known places where MLton deviates from the Definition of SML.

- MLton does not correctly parse case expressions nested within other matches. For example, the following fails.

      fun f 0 y =
            case x of
               1 => 2
             | _ => 3
        | f _ y = 4

  The fix is to parenthesize the case expression.
- MLton rejects rebinding of constructors with `val rec` declarations, as in

      val rec NONE = fn () => ()

  The Definition (bizarrely) requires this program to type check, but to raise `Bind`.
- MLton does not hide the equality aspect of types declared in `abstype` declarations. So, MLton accepts programs like the following, while the Definition rejects them.

      abstype t = T with end
      val _ = fn (t1, t2 : t) => t1 = t2

      abstype t = T with val a = T end
      val _ = a = a

  One consequence of this choice is that MLton accepts the following program, in accordance with the Definition.

      abstype t = T with val eq = op = end
      val _ = fn (t1, t2 : t) => eq (t1, t2)

  Other implementations will typically reject this program, because they make an early choice for the type of `eq` to be `''a * ''a -> bool` instead of `t * t -> bool`. The choice is understandable, since the Definition accepts the following program.

      abstype t = T with val eq = op = end
      val _ = eq (1, 2)