First, let’s just dispense with the details and show you a working example, yes, this is working code:

Code
public void onModuleLoad() {
    $("div").css("color", "red").click(new Function() {
      public void f(Element e) {
        Window.alert("Hello");
        $(e).as(Effects).fadeOut();
      }
    });
  }

If you haven’t seen that before, and if the left side of you brain didn’t just rupture the coronal suture between the frontal and parietal bones of your skull, then get find an absorbent mop and read it again.

Inheriting and using GQuery is as easy as importing in to your module. Of course you need to download and build GQuery, then try it out!

<module ...>
  <inherits name='com.google.gwt.query.Query'/>
  ...
</module>

In addition to normal GWT, here’s the super cool topics we’ll be covering:

• Code splitting — dynamically download different parts of the GWT app for efficiency
• GWT integration with poplar toolkits (e.g., jQuery, ExtJS, etc.) through JSNI
• Code generators and resource generators
• Mashups and cool service integrations
• Lots more!

This course is especially good for J2EE developers who don’t feel completely (or even at all) comfortable in JavaScript or the browser environment — you will end your time with us with some amazing “Browser Fu“!

for(mbr <- collection) {
  println(mbr)
}

Not surprisingly, this loop prints out the members of the collection, in order that they are returned by the collection’s iterator. In fact, this loop construct is translated exactly to

collection.foreach(mbr => println(mbr))

val transformed = for(mbr <- collection) {
  yield transform(mbr)
}

Each time through this example loop, the result of the loop is yielded out. All the yielded results are collected in to a single iterator. This type of for loop is syntactic sugar for the following statement

val transformed = collection.map(mbr => transform(mbr))

That’s right, a simple for…yield loop is just syntactic sugar for Iteratable.map().

Infinite (or extremely large) iterables, usually implemented as Streams or Ranges, are a bit tricky. For example, it probably wouldn’t surprise you to learn that the following traditional for loop will not terminate (at least not in your lifetime):

for(i <- 0 to 100000000000) println(i)

But executing this next for…yield loop does not cause an indefinite wait — it works fine! (Go ahead, try it out!)

val numberStrings = for(i <- 0 to 100000000000) yield ("" + i)

How can this be so? You need to know that o to 10000000000 results in a Range object, which is a non-strict iterator. That is, it is an iterator that calculates the “next” value as you iterate through it, rather than pre-computing all members up front and storing them in memory when the Range is created.

Iteratable functions that yield a scalar result, like foldLeft() or length() or any catamorphic function, are not safe to use with non-strict iterators, because these methods must iterate over the entire iteratable’s contents to produce a result. The foreach() method falls in to this unsafe category — foreach()’s return type is Unit, which is considered scalar.

Remember the traditional for loop is just syntactic sugar for a foreach() call, and this explains why looping over the range with a traditional loop causes an indefinite wait.

Iteratable functions that yield results of similar size to the input, such as map() and flatMap(), are perfectly safe to use with non-strict iterators. These methods themselves yield non-strict iterators, and don’t need to iterate over the source iterator’s contents to yield a result.

The for…yield loop is just syntactic sugar for a map() call, and this explains why looping over the Range with a for…yield loop doesn’t cause an indefinite wait.

End of Interlude

// Using the guarded for...yield loop syntactic sugar
val oddSquares =
  for(i <- 0 to 10000000000 if i % 2 == 1) yield (i*i)
 
// Exactly the same thing as
val oddSquares = (0 to 10000000000).filter(i=>i % 2 == 1).map(i=>i*i)

And as the example implies, this for loop style is non-strict collection safe (because both filter() and map() are non-strict safe).

// Long-winded nested for loop
val pairsThatSumTo100 =
  for(i <- 0 to 100;
      j <- i to 100 if i + j == 100)
    yield Pair(i, j)
 
// Slightly shorter but harder to read raw form that gets compiled
val pairsThatSumTo100 =
  (0 to 100).flatMap(i=>(i to 100).filter(j=>i+j==100).map(j=>Pair(i,j)))

Note that nested for loops are also non-strict safe, because filter(), map() and flatMap() are all non-strict safe. Only the traditional for loop is not safe for non-strict use.

In functional programming, catamorphisms are embodied in the folds functions. I like Scala, so I’ll discuss some catamorphic function examples in found in the standard Scala library’s Iterable trait.

The Iterable trait in Scala represents the concept of an ordered series of same-typed values. This trait is common to all the collection types (Lists, Seqs, and Streams, and many other “series like” things). The Iterable trait defines several catamorphic functions — functions which reduce the series of values down to a single value.

Perhaps the simplest to start with is the forall() and exists() methods. These methods each take a Boolean test operation, applies it to each member of the Iterable, and returns the logical AND (forall()), or OR (exists) of the test values. Despite the fact that they act differently, both methods have the same type signature, because both are Boolean catamorphisms:

trait Iterable[A] {
  ...
  def forall(test: (A) => Boolean): Boolean = ...
  def find(test: (A) => Boolean): Boolean = ...
  ...
}

Event more generic are the foldLeft() and foldRight() methods in Iterable. foldRight() is really just a slight tweak on foldLeft(), so I’ll just explain left-hand version and for the right-hand version I’ll just do some… erm… hand-waving.

The foldLeft() method receives an aggregator function used to combine each member of the Iterable successively in to an aggregated value. foldLeft() starts with an initial value, which it combines with the first Iterable value using the aggregator function. The result is then aggregated with the second Iterable value; and then the third, and so on, until the entire Iterable has been reduce down to a single aggregated value. Thus foldLeft() is a catamorphism, as it combines and reduces the series of values represented by an Iterable down to a single value.

foldRight() is the same as foldLeft() — the only difference being which end of the series each starts with. The foldLeft() function starts with the head of the series (traditionally drawn to the left of the tail — hence the name) and proceeds to the coda; foldRight() starts with the series coda and proceeds to the head.

trait Iterable[A] {
  ...
  def foldLeft[B] (initialValue: B)(aggregatorFunc: (B, A) => B): B = ...
  def foldRight[B](initialValue: B)(aggregatorFunc: (B, A) => B): B = ...
  ...
}

If you think for a second, you can see how forall() and exists() could be implemented using foldLeft():

trait Iterable[A] {
  ...
  def foldLeft[B] (initialValue: B)(aggregatorFunc: (B, A) => B): B = ...
  ...
  def forall(test: (A) => Boolean): Boolean =
      foldLeft(true)(_ && test(_))
 
  def exists(test: (A) => Boolean): Boolean =
      foldLeft(false)(_ || test(_))
  ...
}

In addition to forall() and exists() there are other catamorphic convenience functions in Iterable, and as it turns out each of them could be re-implemented using foldLeft() (or foldRight()) as well. For example, mkString() creates a string representation of the Iterable series by combining each member’s toString() value, along with a prefix, a suffix, and a list separator string.

trait Iterable[A] {
  ...
  def foldLeft[B] (initialValue: B)(aggregatorFunc: (B, A) => B): B = ...
  ...
  def mkString(prefix: String, separator: String, suffix: String): String =
      foldLeft(prefix)(_ + separator + _) + suffix
  ...
}

We’ve published an in-depth description page, or you can go to visit the ticket purchasing page right away. GWT is an extremely valuable tool to add to your development toolkit. This amazing in-depth instruction will up your personal capitol, and your developer skill-set, quickly!

We’ve got several open seats of the date of this posting, so we’re trying something novel to get those seats sold: every day until Jan. 25, the price of each seat is going down by $300! On Jan. 19, the price was $2,000 for all 5 instructional days (normally $3,750). The next day, Jan. 20, the price went down to $1700, and so on.

If there are still seats open on Jan. 25th, they will sell for just $500 for all 5 instructional days!

You can also purchase fewer than 5 days. If you just want a quick instruction to GWT, attend just days 1 and 2. For more in-depth mastery of GWT, attend days 3, 4, or 5! Its up to you to decide how to increase your personal value and abilities as a developer with this unique set-up.

Location, BTW, is at the Smart-Soft training location in Irvine, CA.

Tony Morris is this incredibly knowledgeable and opinionated (in a good way) CS professor who I know because of his swaggering around the Scala-Users mailing list. I love Tony because he takes the time to try explain important CS concepts, as in this video.

The slides in the video are incredibly fuzzy. From Tony’s website, the talk’s slides.

1. Abstract Type Members. Prior to reading the paper, I figured abstract type members are just another way of expressing type parameters — that is, generic type params in Java. Not so! Abstract type members turn out to be an incredibly important  way of promoting code re-use through subtype parameters.
2. Traits. “Module mix-in components” is the term used in the paper, but in Scala this means traits. The paper explains how traits promote code re-use through much more flexible composition than Java’s interfaces+single base class.
3. Explicit Selftypes. Not so mind expanding as abstract type members and traits, but definitely a concept that needs anchoring for someone coming from Java or similar OO languages.

• scala.xml (free e-reference). From the preface: “We shed light on Scala’s XML data model and the syntax of literal XML markup in Scala code.”
• A Tour of Scala: XML Processing (from Scala Wiki). Useful tutorial of Scala XML processing and progamming, plus description of data-specific XML tool schema2src.
• IBM devWorks paper on Scala and XML, by Michael Galpin. Published Apr ‘08, so a little old at this point, but still a good intro.

Quick Explanation of the Pipe Operator

The pipe operator is syntactic sugar that makes certain patterns of code easier to read. When generating a final result by a sequence of value calculations its easier to read the sequence from left -to-right, but Scala  only supports passing values to functions in function(value) form, which basically forces the eyes to read the sequence in right-to-left order — rather unnatural.

Here is one way of expressing a sequence of calculations, relying on local vals to hold intermediate sequence values:

def shuffle(str: String): String = . . .
def randomize(str: String): String = . . .
def camelCase(str: String): String = . . .
def futzWith(str: String): String = . . .
def applySeveralStringTransforms(str: String): String = {
  val shuffled = shuffle(str)
  val randomized = randomize(shuffled)
  val camelCased = camelCase(randomized)
  futzWith(camelCased)
}

Which reads easy enough — the result of the function is the result of shuffling, randomizing, camel-casing and finally futzing with the original String. And here’s the equivalent calculation as a single expression, without local vals. Note how the sequence of calculations is performed from right to left — first shuffle, then randomize, etc.

def applySeveralStringTransforms(str: String): String = {
  futzWith(camelCase(randomize(shuffle(str)))
}

A pipe operator allows you to pass the result of an expression to the right, preserving left-to-right visual order while still being semantically equivalent to either form above:

def applySeveralStringTransforms(str: String): String = {
  str |> shuffle |> randomize |> camelCase |> futzWith
}

Attempt # 1: Right-Associative Operator

My first attempt has me defining a right-associative operator, using Odersky’s pimp-my-library technique, to generate a temporary PipeFunc object which has a “|>:” operator. That is, I’m using a couple tricks to get the compiler to automatically rewrite this

x |>: func

like this

(new PipeFunc(func)).|>:(x)

Since my operator “|>:” ends with a colon, Scala treats it as a “right-associative” function — a function of the right-operand “func”, rather than a function of the left-operand “x”. A very short-lived PipeFunc object gets created by an implicit conversion, and this object has a method named “|>:” that gets applied.

Here’s the definition of my operator:

object Pipeline {
  implicit def toPipeFunc[X, Y](func: X => Y) = new PipeFunc(func)
  class PipeFunc[X, Y](func: X => Y) {
    def |>:(value: X): Y = func(value)
  }
}

There are immediate problems with this approach. Because of how Scala 2.7.5 (the version I am using) parses this code, it is apparently unable to recognize that the right-hand side of |>: is a function reference. So the following actually causes a compiler error:

// complains "|>:" is not a function of type Unit
"Hello, World!" |>: println

I’m not sure why this is, but using parens fixes the problem, but makes the expression too surprising and ugly for my taste. I’m going to have to go back to the drawing board…

Attempt #2: Left-Associative Operator

Instead of augmenting the function argument on the right, I’ll try augmenting the value argument on the left with a “|>” operator. I’ll use the same pimp-my-library technique to use an implicit conversion of the left-hand object to a temporary object that has a “|>” operator, which takes a function as its right-hand argument. That is, I’m using a couple tricks to get the compiler to automatically convert this

x |> func

to this

(new PipeLink(x)).|>(func)

Here’s my code for the operator definition:

object Pipeline {
  implicit def toPipeLink[X](v: X): PipeLink[X] = new PipeLink[X](v)
  class PipeLink[X](value: X) {
    def |>[Y](func: X => Y): Y = func(value)
  }
}

OK, works correctly, and doesn’t have any of the problems that the right-associative operator had.

I do have a hidden performance issue: creation of an very-short-lived temporary object. Consider how the the following single expression gets rewritten by the Scala compiler:

str |> shuffle |> randomize |> camelCase |> futzWith

to this:

(new PipeLink((new PipeLink((new PipeLink((new PipeLink(str)).
    |>(shuffle)).|>(randomize)).|>(camelCase)).|>(futzWith)

Ugly – obviously; wastefully creates too many objects – also true. 4 temporary PipeLinks created and thrown away. The JVM GC is pretty good at handling short-lived objects, but this is terribly wasteful. I can’t think of a way of getting rid of temporary objects — any suggestions greatly appreciated!

Smarter Than Me

Only after implementing did I find that Steve Gilham had already posted his implementation of the pipe operator. He immediately went with a left-associative operator implementation. Must be a clever guy! Both his solution and mine suffer from creating a temp object with each invocation of the pipe operator.