Scala Language

Hi, I found the following behavior of the flat-map operation
confusing:

scala> val m = Map("a" -> List(11,111), "b" -> List(22,222))
m: scala.collection.immutable.Map[java.lang.String,List[Int]] = Map(a -
> List(11, 111), b -> List(22, 222))

scala> m.flatMap(_._2) // Expected behavior
res: scala.collection.immutable.Iterable[Int] = List(11, 111, 22, 222)

scala> val m = Map("a" -> List(1 -> 11,1 -> 111), "b" -> List(2 ->
22,2 -> 222))
m: scala.collection.immutable.Map[java.lang.String,List[(Int, Int)]] =
Map(a -> List((1,11), (1,111)), b -> List((2,22), (2,222)))

scala> m.flatMap(_._2) // Surprising behavior, a map is created and 2
tuples are missing(overwritten)
res: scala.collection.immutable.Map[Int,Int] = Map(1 -> 111, 2 -> 222)

Paul discussed with me a little bi

Hi!

The question has been asked a few times already (I even asked it myself here http://stackoverflow.com/questions/3795404/why-does-scalaobject-exist) and it has been coming up in my mind after seeing what some optimizations to the "implements" part of class files have done to the class file size.

Is there any reason left why we still make many classes implicitly implement that type?
Checking if something implements ScalaObject has never been a reliable check if something is a Scala class and I can't imagine another usage after the $tag stuff was removed before 2.8.

After reading the compiler sources a bit it seems that it is not really a "core part" of anything.

Hey folks,

From http://youtrack.jetbrains.net/issue/SCL-3958:

val someSeq: Seq[Int] = Vector(1,2,3)

// This throws a MatchError because someSeq isn't a list
someSeq match { 
  case x :: xs => "non-empty list starting with " + x
  case Nil => "empty"
}

// This is a correct version that works with lists too
someSeq match {
  case Seq(x, xs @ _*) => "non-empty seq starting with " + x

A gentle reminder... deadline for submitting to the Scala Workshop is Jan 16.One free registration voucher per accepted paper!
best wishes for 2012,adriaan

On Thu, Nov 17, 2011 at 4:00 PM, Adriaan Moors <adriaan [dot] moors [at] epfl [dot] ch> wrote:

Dear Lists,

It seems that guarded match expressions are not tested for
completeness at compile time.

I'm getting this odd message in the Scala REPL:

[line elided for control chars: possibly a scala signature]

Can someone tell me what this is all about?

Thanks,
Robert

Hi all,

My company ran into a pretty serious issue yesterday in the process of trying to migrate our stack from Scala 2.8.1 to 2.9.1. We are in the (unfortunate) situation of still being heavily reliant on Jersey for web services. We were also making heavy use of traits in our REST resources for modularizing shared behavior. Yesterday, we discovered that methods defined in traits are treated as bridge methods in concrete classes that mix them in. Jersey ignores bridge methods when collecting a resource's methods. This is a serious problem for us. What's the motivation for this new behavior in Scala 2.9.1?

Zeebox (http://zeebox.com, http://www.scala-lang.org/node/11428) is a startup based in Central London, which in less than 12 months has built a great team, secured funding and actually delivered working product to market.
We are expecting an even busier 12 months ahead, so if you are interested in joining the team contact me directly via this address or kevin AT zeebot DOT com