SIDEBAR
»
S
I
D
E
B
A
R
«
Scala Refactoring: Quiet-my-scope with an Implicit Parameter vs. Pimp-my-lib with an Implicit Conversion Method
May 30th, 2011 by Brian Maso

The following two code snippets are equivalent, differing only on what the client code ends up looking like, but yielding in all other ways similar results:

// --------------------
// In LibraryCode.scala...
package library.code;
 
// client code expected to import the following method and provide
// an implicit Thing value for t -- a "quiet-my-scope" patterned method.
def addedFeatureToSomeThing(implicit Thing t) = ...
 
// --------------------
// In ClientCode.scala...
import library.code._
 
// An implicit Thing value
implicit val someThing: Thing = ...
 
// Use of the someThing value as an implicit parameter to the library method
val result = addedFeatureToSomeThing

The code above can be refactored to the pimp-my-lib style which follows, and vice versa:

// --------------------
// In LibraryCode.scala
package library.code;
 
// client code expected to import the following implicit conversion method,
// which effectively adds a new method "addedFeature" to the Thing class in the importing scope.
implicit def convertThingToAddFeature(t: Thing) = new {
    def addedFeature = ...
    }
 
// --------------------
// In ClientCode.scala...
import library.code._
 
val someThing: Thing = ...
 
// Use of the pimp-my-lib-patterned convertThingToAddFeature implicit conversion method
val result = someThing.addedFeature

In both cases, the imported LibraryCode.scala provides a callable method which requires state in the form of a Thing object. I’m assuming the Thing type is also defined external to the client code — probably in a third-party library.

The first pattern, which to the best of my knowledge doesn’t have a name, you have a method in the local scope which accepts an implicit parameter, and effectively allows you to pass a single in-scope object to multiple methods without needing to repeat yourself. I’m going to dub this the “quiet-my-scope pattern“, because it reducesĀ  the visual chatter that would otherwise be caused by passing the same object to multiple method calls — and I’ll just hope that name sticks.

The second is the famous pimp-my-lib pattern, which is well-known throughout Scalaland to be used to “add” methods to externally-defined classes.

Using implicits we have these two API patterns to choose from — they are equivalent, in so far as an implementation of either one can be mechanically transformed in to the other, only style and convenience being a differentiator between them. You might find it useful to keep around this alternative to the pimp-my-lib pattern, as in some APIs it will yield more readable, more convenient code.

Try it out: the next time you find yourself augmenting an existing class with methods using the pimp-my-lib pattern, take 5 minutes to refactor your solution to methods with implicit parameters (using the sample Thing code above as a guide). You won’t lose much time in the exercise, and you may find you’ll end up with better code.

Similarly, the next time you find yourself defining a method with an implicit parameter, take 5 minutes to work through what a refactored solution with a pimp-my-lib style method would look like. You may like the result quite a bit more than what you started with.

def addedFeatureToSomeThing(implicit Thing t) = …

 

Scala Word of the Day: For Loops (All 4 Kinds!)
Jan 22nd, 2010 by Brian Maso

You think you know how to define a for loop, do you? Scala has 4 different kinds.


1. Traditional for loop. Loops through the members of an Iteratable. The result of the loop block is Unit.

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))

2. For…Yield Loop. Use the yield keyword within the body of a for loop. The loop block has a result which is an iterator of the yielded results. Thus the for loop can act as the RHS of an assignment.

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().


Interlude: Watch Out for Infinite Iterables

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


3. Guarded For…Yield Loop. Throw an if guard in to a for..yield loop, and its translated to a filter-map pipeline (perhaps I should say filter |> map, using the pipe operator).

// 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).


4. Nested For Loop. Nesting iteration over iterators is syntactic sugar for a nested flatMap() call. Stare at the loop below and the form it gets translated in to by the Scala compiler for a little bit, you don’t need my explanation:

// 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.

Scala Word of the Day: Catamorphism
Jan 20th, 2010 by Brian Maso

Catamorphism is the $20 word for a function that condenses a set of values down to a single value. For example, in SQL the terms grouping function or aggregator function refer to catamorphic functions, which includes SQL functions AVERAGE(), SUM(), and MEDIAN(). All of these SQL functions have in common a pattern that operates on a set of numeric values, and returns a single numeric value.

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
  ...
}
»  Substance:WordPress   »  Style:Ahren Ahimsa