[MLton] bug? pattern-matching against value-carrying constructors

[Stephen Weeks]

> A simple one-line example is this:
> 
>     fun f x = case x of SOME => true | _ => false
> 
> When i try to compile this program with MLton 20041109, i get a
> 12898-line error message ending with "unhandled exception:
> TypeError".  Is this a bug?

Yes it is a bug.

> Andreas Rossberg's HaMLet *might* be what the Definition calls for,
> but it's very counterintuitive in my opinion:
>
>     HaMLet 1.2 - To Be Or Not To Be Standard ML
>     [loading standard basis library]
>     - fun f x = case x of SOME => true | _ => false;
>     val f = <fn> : ('a -> 'a option) -> bool

I also think this is counterintuitive, although rule 35 of the
Definition allows it.  I can't find anywhere a restriction that unary
constructors must be applied to an argument pattern.

For even weirder behavior, feed Hamlet the following program.

  fun f x = case x of SOME => true | _ => false
  val b1 = f (fn _ => raise Fail "")
  val b2 = f SOME

Hamlet decides that b1 = false and b2 = true, implying that Hamlet is
doing an equality comparison on values of functional type.  This does
look like what rule 13{6,7} of the Definition call for, but I think it
is an error.

Yes, this is definitely weird.  Feed Hamlet

  datatype t = A of unit | B of unit | C of unit
  fun f x = case x of A => 1 | B => 2 | C => 3
  val n1 = f A   
  val n2 = f B
  val n3 = f C

That's right, you'll get n1 = 1, n2 = 2, n3 = 3!