Posts Tagged ‘scala’

Rise of the Community - Phase Two

Wednesday, September 3rd, 2008

It is a few days ago that I volunteered to maintain scalap. Writing with Scala has been more than fun and I decided it was time to write for Scala. My time is limited, but the barrier has been, at some percentage, a psychological one. Dealing with the very stuff itself, is something to be taken seriously.

Yesterday, I was glad to read, Scala Team’s open request for maintainers from the community. The Scala community has already been very energetic and passionate: No egoisms, eager to provide help in its members, active at reporting bugs and even patches or new implementations. David R. McIver quickly responded and is now probably washing his hands before diving into the pattern matcher.

At these very moments, we are experiencing a new rise of the community!

Enter reflection, meet type unsoundness

Sunday, August 17th, 2008

The theoretically-inclined may judge if the subject correctly characterizes the situation I am about to describe.

At some point while programming a library (in Scala, of course), I thought it would be a nice idea to abstract over some compiler-powered magic regarding the handling of for-comprehensions, and in particular those compiled to foreach() calls. So, I came up with this:


type ForEach[T] = {
  def foreach(f: T => Unit): Unit
}

Now, let’s define a generic function:


def foreachWrapper[T](container: ForEach[T], f: T => Unit) {
  for(value < - container)
    f(value)
}

So, any type adhering to the ForEach structural contract can be passed to foreachWrapper. Of course this is a trivial function, but suffices for the purpose of this post.

Now, we know that Lists and Arrays are specially handled by the compiler when appearing in a for(v <- c) construct, and we deserve the right to believe that this:


foreachWrapper(List(1, 2))

and this:


foreachWrapper(Array(1, 2))

will type-check. And indeed they do, as expected. So our program is correct.

But if we try to run it (see the complete code at the bottom of this post), we get an exception:


java.lang.NoSuchMethodException: [I.foreach(scala.Function1)

Hmmmm.... What the Hack??? The situation is blurred (note that [I is the class of an integer array in Java). But wait a minute!

We know that structural types, implementation-wise, interfere with reflection, and there is where the exception comes from. And this is all because Scala does its best to handle arrays in the most balanced way.. Array(1, 2) is compiled to a respective Java array but Java arrays do not define a foreach method!

As expected, If we force Scala to box the array, using this trick:


def boxMe[T](me: Array[T]): Array[T] = me

then there is no problem at all…

C’est la vie. You get something, you lose something else…

The complete code follows:


object foreach {
  type ForEach[T] = {
    def foreach(f: T => Unit): Unit
  }

  def foreachWrapper[T](container: ForEach[T], f: T => Unit) {
    for(value <- container)
      f(value)
  }

  def boxMe[T](me: Array[T]): Array[T] = me

  def rollIt[T](container: ForEach[T]) {
    println("-- Iterating over: " + container.getClass.getName)
    foreachWrapper(container, println)
  }

  def main(args: Array[String]) {
    val intList = List(1, 2)
    val intArray = Array(1, 2)

    rollIt(intList)
    rollIt(boxMe(intArray))
    rollIt(intArray)  // Exception!
  }
}

Language-Level LazyVals in Scala

Thursday, July 24th, 2008

[This is from http://www.nabble.com/Question-on-lazy-val-td17678892.html]

For what it’s worth, I fast-coded a hack that implements lazy vals at the language level, mimicking the compiler’s implementation. It turns out 120% slower that built-in lazy vals, if using the client HotSpot (default) and 40% slower if using the server HotSpot (java -server).

It does not leak (?) and the memory footprint is worse than the built-in solution.

final class LazyVal[A](f: => A) {
  private[this] var _f = f _
  private[this] var _value = null.asInstanceOf[A]
  def value = {
    if(null != _f) synchronized {
      if(null != _f) {
        _value = _f()
        _f = null
      }
    }
    _value
  }
}

The private[this] things are needed so that field accesses (as compiled by scalac) do not go through methods, although I have noticed that HotSpot is doing a great job even without them.

Re: The Mysterious TreeMap Type Signature

Thursday, January 24th, 2008

[This is a comment on the recent post The Mysterious TreeMap Signature by D. Spinellis, also posted in his blog.]

Recently I had to delve into Java Generics quite deep, since I (as my search concluded) needed to use

public class Foo<t extends Foo<T>>

recursive constructs for a personal project (which by the way are fixed-point equations of the form x=f(x) !). The point is I had to read a lot (including Anglelika’s marvelous contribution) in order to understand what is going on beyond the overhyped and embarassingly simplistic for-each construct.

Unfortunately, it seems the JDK is full of compromises of the kind described in the post. I do not argue that compatibility is a bad issue. I am just concerned with what else will follow in the road to Java evolution, since I do not want to see this wonderful and very pragmatic language become lame.

About five years [correction: after thinking better about it, I believe it is more than six or seven years] ago, I envisioned a merging of the Functional and Object-oriented paradigms. This need had come out my experience in designing and programming. I had next-to-none experience with FOP, but it was too obviously appealing to my brain to ignore it… Today, I would like to experiment with scala a bit, time permitting…