[MLton] bug? pattern-matching against value-carrying constructors
Stephen Weeks
MLton@mlton.org
Wed, 20 Jul 2005 22:25:34 -0700
> 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!