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

[Andreas Rossberg]

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