(fwd) Re: Ouch! The pattern matcher bit me.

Some more evidence that martin and I are programmers, not emailers:

... and forwarding this one as well. I have to eradicate this wrong
scala-internals address from my mail contacts.

On Fri, Sep 25, 2009 at 10:08:39PM +0200, martin odersky wrote:
> >   // TODO - scala> (5: Any) match { case 5 => 5 ; case 6 => 7 }
> >   // ... should compile to a switch.  It doesn't because the scrut isn't Int/Char, but
> >   // that could be handle in an if/else since every pattern requires an Int.
> >   // More immediately, Byte and Short scruts should also work.
> >
> No idea who wrote that and when. But it's interesting.

Oh I'm sorry, by "comment I have in the source" I meant "comment I have
written in the source." I am the comment's author. You can tell by the
incredible verve - it has that page-turning quality normally only found
in epic thrillers.

[I once again managed to send this to the fake -internals address. Oh
archived email, why do you mock me.]

On Fri, Sep 25, 2009 at 08:16:52PM +0200, martin odersky wrote:
> Furthermore, I notice that there is indeed boxing going on at erasure.
> That by itself is very bad. Why do we box here?

OK! As of r18820 it is a different story. Here is a test case:

object o {
val xs = Array[Byte](95)
val C: Char = 95.toChar
val I: Int = 152
val L: Long = 439587438l

xs(0) match {
case C => true
case I | L => true
case 957 => true
case _ => false
}
}

Right off the bat, the size of the javap output tells a good story:

-rw-r--r-- 1 paulp wheel 9351 Sep 29 05:29 bad.txt
-rw-r--r-- 1 paulp wheel 6875 Sep 29 05:29 good.txt

Here is a typical before/after section:

< 92: iload_1
< 93: invokestatic #76; //Method scala/runtime/BoxesRunTime.boxToByte:(B)Ljava/lang/Byte;
< 96: aload_0
< 97: invokevirtual #90; //Method I:()I
< 100: invokestatic #94; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
< 103: invokestatic #87; //Method scala/runtime/BoxesRunTime.equals:(Ljava/lang/Object;Ljava/lang/Object;)Z
< 106: ifeq 113

> 84: iload_1
> 85: aload_0
> 86: invokevirtual #76; //Method I:()I
> 89: if_icmpne 96

Hi All,

I have a compiler bug that shows up in 2.7.5 but not 2.8. I'm guessing
that it was already reported but it was decided to fix it in 2.8 but
not 2.7.x. The bug is a compiler stack trace when I have a method that
takes a varargs. I'm not sure exactly what is necessary to make the
bug show up, but I can submit an example from ScalaTest that makes it
happen.

Since this seems to be fixed in 2.8, should I not submit the bug to
Trac? Or would you prefer I submit it anyway.

Thanks.

Bill
----
Bill Venners
Artima, Inc.
http://www.artima.com

Hi Bill,

No if it's fixed in trunk, we don't need a ticket.

Thanks