[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