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

**Andreas Rossberg
**
AndreasRossberg@web.de

*Thu, 21 Jul 2005 20:35:06 +0200*

Stephen Weeks <sweeks@sweeks.com> wrote:
>*
*>* > 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.
*
I think the second side condition of rule 35 enforces it: the instantiated
type of the constructor must be of the form tau^(k) t, and in the above case
it clearly isn't. So this is a bug.
>* 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.
*
Well, if you omit type checking - or /I/ get it wrong :) - then you get what
the dynamic semantics specifies, without qualms...
>* 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!
*
Pretty cool! Who the heck needs type checking getting in the way of a nifty
feature like this? :-)
Cheers,
- Andreas