Yes, Virginia, Scala can save you from Null Pointer Exceptions.

First, Virginia, let me tell you that I don't know why everybody in the Scala community is writing to to you, I guess is because you're curious and want to learn about it, or maybe you know where to find the  mythical "average programmer". But I digress...

Let's focus on the subject of this post: how you can prevent null pointer exceptions with Scala. Suppose you have your tidy Scala code in functional flavor with all the fixes, and you need to do a series of calls to a Java library, where each value depends on the previous value: let's say you want to call functions A,B,and C.
  val x=A(in)
  val y=B(x)
  val z=C(y)

(or C(B(A(in))) if you like )

Now, is common in Java to return null when no value can be returned or even throw an exception if something goes wrong. How we prevent that? The naive approach will be to chain the ifs:


   val x=A(in)
   if (x != null){
       val y=B(x)
       if (x != null){
         val z=C(y)
       }
   }

I don't know you, but for me that style doesn't cut it anymore, is too verbose! And now our flow is littered with null checks, obscuring the purpose.
So, what we can do? I know! Let's use Scala's Option and write a small function that returns "Some" value or "None" if we got null or something wrong happened:



Nothing fancy here, Option(x) will evaluate x and return Some(x) if it has a value or None if is null. The only noteworthy thing here is in the signature: it defined as " x:=> T " that roughly means "any function that returns something of type T", so x will be evaluated when we actually use it and not when we call the function, otherwise we risk getting the exception before entering the try block.

 Ok, so now we wrap every function call with our unsafeCall function, but now we have a problem, the types don't match! We can't just chain the calls, we need to extract the value from the Option first!
We can try with pattern matching:

  A(x) match {t
    case None => _
    case  Some(y) => B(y) match {
      case None => _
      case  Some(z) => C(z)
    }
  }

But it looks clumsy and we don't gain much compared to the "if not null" version, what we can do?
Let's take a step back and look at the types: we want to chain a series of function with T=>Option[T] ... does it ring a bell? What if we write as T=>M[T] ? If you've said the M-word, bingo!
Some[_] is a monad, and that means we can use Scala's "for" notation.
Let's tie everything together in one example:

ADENDUM: This is a toy example for illustrative purposes. I guess I should have left out the exceptions, otherwise is almost the same result as surrounding everything with a try/catch. Also, is an exception happens, we want to know what happens, for that Either is more suitable than Option (I'll leave that for another blog post). Still, when you need to chain a series of functions that return Some/None, for comprehensions gives you a nice sugar ;)

Functors, Applicative Functors, and Monads aren't that scary

I'm currently reading "Learn You a Haskell for Great Good" (really great book, if you want to learn Haskell, you can read it online or better, buy it now! ) and it has a very good explanation of Functors, Applicative Functors, and Monads. I refuse to write another Monad tutorial (I'm not knowledgeable enough) but I'll write about what I've understood so far. (Be kind enough to correct me)

Here is all you need to know about functors, applicative functors, and monads (Haskell code):



Or it's equivalent Scala code:


Crystal clear, isn't it? Just kidding.
IMPORTANT NOTE:THIS ARE ONLY THE THE TYPE SIGNATURES, ANY IMPLEMENTATION HAVE TO COMPLY WITH THE FUNCTOR/MONAD LAWS (see ADENDUM at the bottom)

The TL;DR version
Want to apply a function to things in some "context"? Use a functor.
The functions are already in some "context"? Use applicative functor.
What if your function put things in the "context"? Use a Monad (... and flatMap that shit!)
That's all you need to know.


Functor
Let's start with the functor.
First, the trait has a type parameter, T[_] (it's a polymorphic type constructor or higher kinded type, but you aren't the type that get scared easily, right?)
For now, you can consider it as a "context": it can be a data structure, like a list, or something else that holds the parameter type inside plus whatever you want to add.
Let's look now at the method signature:
  def fmap[A,B](f:A=>B)(ta:T[A]):T[B]
You take a function f from A to B, and ta context of A and returns a context of B.
In Scala collections is the map function. It transforms T[A] into T[B] by applying f to the elements wrapped "inside" T[A].
That's all you need for a functor! It doesn't look that scary...

Applicative Functor
Now let's look at the applicative functor. For starters, the applicative functor is also a functor (I guess the "functor" in the name is a big hint) so we have the map function available.
With map, you can apply functions to things already in some context, but what if what you have in the context are functions? you need more than fmap to apply them.
Enter the applicative functor.
The applicative functor defines two methods pure and <*>:
  def pure[A](a:A):T[A]
Pure is for putting things in the context, it takes an element of A and returns that element in the minimal context that makes sense (e.g. for lists, would be a list with a single element a).
The next function, "apply" or <*> (you can call it advanced TIE fighter or clenched angle arse if you want) takes functions already in the context and applies them to values in the context, yielding the results also in the context. The way it combines the functions with the values depends on the implementation of the applicative functor itself (e.g. for lists, it applies every function in the list of functions to every value in the list of values).
You can see Tony's message to the Scala mailing list for an amazing example of why the applicative functor is useful.

Monad
And now, the famous Monad !. Monads are applicative functors, but with another method ">>=" (in Scala, you know it as flatMap ). We saw that applicative functors are like functors but the <*> allows you to apply functions already in a context unlike fmap wich needs the functions directly. But what if you have a function that takes a value of A (outside a context) and returns a value of b in the context? (they're pretty common: think of a function that may fail, returning Option[A] ). To apply those kind of functions to things already in the context is why we have >>= function: is pretty similar to the applicative functor's "apply" but instead of a function already in context, it takes a function from A to a context of B.

For my next post, I want to show that using Option as a monad in Scala CAN save you from NullPointerExceptions...

Notes:

• Eric explained most of this way better than me in  "The essence of the iterator pattern"
• The traits above are just for illustrative purposes, for the real thing use Scalaz
• I'm no authority, take all I've said with a grain of salt, I just hope it helps in your explorations. For me, applicative functor was the missing piece in my understanding of monads.

ADENDUM: There's a great (and WAY better than mine) explanation of all of this in Haskell's Typeclassopedia. I don't know why nobody called me on it, but to actually have an instance of Functor/Applicative/Monad the implementation has to obey the following laws:


Functor laws
fmap id = id
fmap (g . h) = fmap g . fmap 




Applicative Functor laws
pure id <*> v = v                            -- Identity
pure (.) <*> u <*> v <*> w = u <*> (v <*> w) -- Composition
pure f <*> pure x = pure (f x)               -- Homomorphism
u <*> pure y = pure ($ y) <*> u              -- Interchange




Monad laws
m >>= return     =  m                        -- right unit
return x >>= f   =  f x                      -- left unit
(m >>= f) >>= g  =  m >>= (\x -> f x >>= g)  -- associativity

Short break for a long hiatus

Hi! Anybody out there?
I guess twitter totally killed whatever energy I had for blogging :)
For lazy people like me, the fact that instead of inaccurately express your idea in a couple of paragraph you're able to slap one phrase and that's enough is fantastic... it doesn't even need to be coherent!






Noteworthy things that happen in between (in no particular order whatsoever):

• I'm learning Scheme by the AWESOME book "The Little Schemer" (Amazon link: The Little Schemer - 4th Edition) and using PLT Scheme / Racket. I'm getting over to my aversion to prefix notation and now I can somehow understand Lisp code and I'm getting ready to learn Clojure 
• I'm back in my home country, Uruguay (go team! we made it to the semifinals!!)
• I badly broke my ankle, had two surgeries and I still limp after a couple of months
• I'm expecting another baby!
• Scala 2.8 is out!!!!!!! Go get it while still hot
• I need to learn Haskell
• I went to the east coast Scala lift-off and meet awesome people
• Don't be afraid of powerful languages, believe it or not, they make your life easier
• I bought more Star wars legos than I needed
• I have a couple of unfinished blog posts that someday I'll finish :)

Thanks for stopping by, I'll promise more useful posts in the future.
(I'm adding a totally unrelated picture of a alien spider I found lying on a wall)

Boolean Algebra Internal DSL in Scala (aka fun with Unicode names )

In Scala, operator names can be characters from the unicode set of mathematical symbols (Sm) or other symbols (So). That can lead to interesting possibilities:


val Π = Math.Pi
def √(x:Double)=Math.sqrt(x)
val x= √(9*Π)


Here, "Π" is just another constant and "√" is a function like "q".
(To use unicode in eclipse, you have to go to Preferences->General->Workspace, and change the text encoding to UTF-16)

Another example: with the ∑ and ∏ you can have define summation and the product of a sequence as follows:


def ∑(r:Range)(f:Int =>Int)=r.reduceLeft(_+ f(_))
def ∏(r:Range)(f:Int =>Int)=r.reduceLeft(_* f(_))


And now we can write:


val s= ∑(1 to 100)(x=>x^2)
val p= ∑(1 to 100 by 2)(x=>x^2)
val y= ∏(1 to 30 by 3)(_)


Of course, I'm not advocating using Scala as a substitute of a specific mathematical tool, besides, there's already a "language with symbols" (btw, I wonder if one can make a Scala "skin" that looks like APL). I'm not sure how other languages can do this (except APL maybe?), but this goes to show the power of Scala for "internal DSL".

For a slightly more complex example, let's define an internal DSL for boolean logic, with the appropriate symbols: ¬,V,Λ,and →.


class LogicBoolean(val value:Boolean) {
import LogicBoolean.¬
override def toString=value.toString

def V(b:LogicBoolean)=new LogicBoolean(this.value || b.value)
def Λ(b:LogicBoolean)=new LogicBoolean(this.value && b.value)
def →(b:LogicBoolean)=(¬(this)) V (this Λ b)
}

object LogicBoolean {
def ¬(a:LogicBoolean)=new LogicBoolean(!a.value)
implicit def boolToLogicBool(x:Boolean)=new LogicBoolean(x)
}


The only prefix operators that can be defined in Scala are ‘+’, ‘’, ‘!’ or ‘~’, so no luck for ¬. But we if we define it as a function, we can import it and use it (almost) like a prefix op. As we want an implicit conversion from boolean to our LogicBoolean class, a companion object is the ideal place to put both. By importing all the methods in the companion, we bring the ¬ operator and the implicit conversion into scope:


import LogicBoolean._

val A=true
val B=false

println("¬A :"+ ¬(A))
println("¬B :"+ ¬(B))
println("A Λ B :"+ (A Λ B))
println("A V B :"+ (A V B))
println("A → B :" + (A → B))
println("B → A :" + (B → A))


With everything in place, with a for comprehension is very easy to print the truth tables of any complex formula (just be careful with the precedence, use parenthesis):


import LogicBoolean._

val r=List(true,false)


def expr(a:Boolean,b:Boolean,c:Boolean,d:Boolean)=
( (a Λ b) V ¬(a Λ c) ) Λ ((c V d) Λ ¬(b) )

//let's print the truth table
println ("\na\tb\tc\td\t(a Λ b) V ¬(a Λ c) ) Λ ((c V d) Λ ¬(b)")
for (
a <- r; b <- r; c <- r; d <- r ) println (a+"\t"+b+"\t"+c+"\t"+d+"\t"+expr(a,b,c,d))

If you run the examples you get:


¬A :false
¬B :true
A Λ B :false
A V B :true
A → B :false
B → A :true

a b c d (a Λ b) V ¬(a Λ c) ) Λ ((c V d) Λ ¬(b)
true true true true false
true true true false false
true true false true false
true true false false false
true false true true false
true false true false false
true false false true true
true false false false false
false true true true false
false true true false false
false true false true false
false true false false false
false false true true true
false false true false true
false false false true true
false false false false false


The ability to easily adapt the language to looks like the domain is one of the main selling features of languages like Lisp. Though Scala is no way like Lisp, it can go very far in the "internal DSL" direction and provides many features to make that easy.

EDIT: Something very similar in Ruby

My take on 99 problems in Scala (23 to 26)

I have lot of things going on, but a quick post. Here are 5 more problems solved in Scala.
Note: in all this and the previous solutions, I've left out (most of the time) boundary conditions checks, to keep the code simple and as elegant as possible.

P23: Random select. We reuse P20 (removeAt) and remove a random element of the list recursively.


//P23

  def randomSelect[A](n: Int, xs: List[A]): List[A] = (n, xs) match {
    case (_, Nil) => Nil
    case (0, _) => Nil
    case (_, _) => {
      val x = removeAt(new Random().nextInt(xs.size), xs)
      x._2 :: randomSelect(n - 1, x._1)
    }
  }

P24: lotto. we create a list (well, actually is a range converted to a list) of the numbers and use P23 to select a random draw.


//P24
def lotto(n:Int,max:Int):List[Int] =randomSelect(n,(1 to max).toList)


P25: random permute. That's easy: we use P23 to do a randomSelect on the whole list


//P25
def randomPermute[A](xs:List[A]):List[A] =randomSelect(xs.size,xs)


P26: combinations. That one wasn't straightforward, I actually had to think! :)
But the solution can be defined recursively:
to get the combinations of size n, take one element of the set and append it to all the combinations of sets of size n-1 of the remaining elements, union the combinations of size n of the remaining elements.
I had to create an auxiliary function that "lift" a list into a list of lists, (kind of the opposite of flatten).


//P26

  def combinations[A](n: Int, xs: List[A]): List[List[A]] = {
    def lift[A](xs: List[A]): List[List[A]] = xs.foldLeft(List[List[A]]())((ys, y) => (List(y) :: ys))

    (n, xs) match {
      case (1, ys) => lift(ys)
      case (i, xs) if (i == xs.size) => xs :: Nil
      case (i, ys) => combinations(i - 1, ys.tail).map(zs => ys.head :: zs) ::: combinations(i, ys.tail)
    }
  }

My take on 99 problems in Scala (first 22)

A while ago I saw 99 problems in Prolog they looked really good and I started trying to solve them in Scala. Now, thanks to Tony Morris I found that there's a Scala version!
Nice stuff to get your skills up to shape. It helped me to improve my understanding of folds, maps, flatMaps, zips, etc. Also I learned new pattern matching techniques (tuples and guards).
You must really give the exercises a shot!
Here are my solutions:




package exercises

object NinetyNine {
  //P01
  def last[A](xs: List[A]): A = xs match {
    case x :: Nil => x
    case x :: xs => last(xs)
    case Nil => throw new NoSuchElementException
  }

  //P02
  def penultimate[A](xs: List[A]): A = xs match {
    case x :: y :: Nil => x
    case x :: xs => penultimate(xs)
    case _ => throw new NoSuchElementException
  }

  //P03
  def nth[A](i: Int, xs: List[A]): A = xs match {
    case x :: xs => if (i == 0) x else nth(i - 1, xs)
    case _ => throw new NoSuchElementException
  }

  def nth2[A](i: Int, xs: List[A]): A = xs match {
    case x :: xs if (i == 0) => x
    case x :: xs if (i > 0) => nth(i - 1, xs)
    case _ => throw new NoSuchElementException
  }

  //P04
  def length[A](xs: List[A]): Int = xs match {
    case x :: xs => 1 + length(xs)
    case Nil => 0
  }

  //Although straight recursion is fun, using folds is more effective
  // folds are abstractions for recursion over data structures

  //P04
  def length1[A](xs: List[A]): Int = xs.foldLeft(0)((a, b) => a + 1)

  //P05
  def reverse[A](xs: List[A]): List[A] = xs.foldLeft(Nil: List[A])((a, b) => b :: a)

  //P06
  def isPalindrome[A](xs: List[A]): Boolean = reverse(xs) == xs

  //P07
  def flatten[A](xs: List[List[A]]): List[A] = xs.foldRight(Nil: List[A])(
    (xs, acc) => xs match {
      case ys: List[A] => ys ::: acc
      case y: A => y :: acc
    })

  //P08
  def compress[A](xs: List[A]): List[A] =
    xs.foldRight(List[A]())((y, ys) =>
      if (ys != Nil && ys.head == y) ys else y :: ys)

  //P09
  def pack[A](xs: List[A]): List[List[A]] = xs match {
    case Nil => Nil
    case _ => xs.takeWhile(_ == xs.head) :: pack(xs.dropWhile(_ == xs.head)) //can use span too, see P13
  }

  //P10
  def encode[A](xs: List[A]): List[(Int, A)] =
    pack(xs).map(y => (y.length, y.head))

  //P11
  def encodeModified[A](xs: List[A]): List[Any] =
    pack(xs).map(
      y => if (y.length == 1) y.head else (y.length, y.head))

  //Type safe version
  def encodeModifiedTypSafe[A](xs: List[A]): List[Either[A, (Int, A)]] =
    pack(xs).map(
      y =>
        if (y.length == 1) Left(y.head)
        else Right(y.length, y.head))

  //P12
  def decode[A](xs: List[(Int, A)]): List[A] = {
    def expand(i: Int, a: A): List[A] = if (i == 0) Nil else a :: expand(i - 1, a)
    flatten(xs.foldRight(List[List[A]]())((y, ys) => expand(y._1, y._2) :: ys))
  }
  //is better with flatMap
  def decode1[A](xs: List[(Int, A)]): List[A] =
    xs.flatMap(ny => List.make(ny._1, ny._2))

  //P13
  def encodeDirect[A](xs: List[A]): List[(Int, A)] = xs match {
    case Nil => Nil
    case _ => {
      val ys = xs.span(_ == xs.head)
      (ys._1.length, xs.head) :: encodeDirect(ys._2)
    }
  }

  //P14
  def duplicate[A](xs: List[A]): List[A] =
    xs.foldRight(Nil: List[A])((y, ys) => y :: y :: ys)
  //is better with flatMap
  def duplicate1[A](xs: List[A]): List[A] = xs.flatMap(y => y :: y :: Nil)

  //P15
  def duplicateN[A](n: Int, xs: List[A]): List[A] =
    xs.foldRight(Nil: List[A])((y, ys) => (1 to n).toList.map(_ => y) ::: ys)
  //is better with flatMap
  def duplicateN1[A](n: Int, xs: List[A]): List[A] =
    xs.flatMap(y => List.make(n, y))

  //P16
  def drop[A](n: Int, xs: List[A]): List[A] =
    xs.zipWithIndex.filter(_._2 % n != 0).map(_._1)

  //P17
  def split[A](n: Int, xs: List[A]): (List[A], List[A]) =
    xs.splitAt(n) // or (xs.take(n),xs.drop(n))

  //ok, that was too easy, let's try recursion
  def splitRec[A](n: Int, xs: List[A]): (List[A], List[A]) =
    (n, xs) match {
      case (0, _) => (Nil, xs)
      case (_, y :: ys) => {
        val rec = splitRec(n - 1, ys)
        (y :: rec._1, rec._2)
      }
      case (_, Nil) => (xs, Nil)
    }

  //P18
  def slice[A](s: Int, e: Int, xs: List[A]): List[A] =
    xs.slice(s, e) // or xs.drop(s).take(e-s)

  //with recursion
  def sliceRec[A](s: Int, e: Int, xs: List[A]): List[A] =
    (s, e, xs) match {
      case (0, 0, xs) => Nil
      case (0, _, y :: ys) => y :: sliceRec(0, e - 1, ys)
      case (_, _, y :: ys) => sliceRec(s - 1, e - 1, ys)
    }

  //P19
  def rotate[A](n: Int, xs: List[A]): List[A] = {
    val s = split((if (n > 0) n else n + xs.length), xs)
    s._2 ::: s._1
  }

  //P20
  def removeAt[A](n: Int, xs: List[A]): (List[A], A) = {
    val (heads, tails) = split(n, xs)
    (heads ::: tails.tail, tails.head)
  }

  //P21
  def insertAt[A](e: A, n: Int, xs: List[A]): List[A] = {
    val (heads, tails) = split(n, xs)
    heads ::: e :: tails
  }
  //with recursion
  def insertRecAt[A](e: A, n: Int, xs: List[A]): List[A] =
    (n, xs) match {
      case (0, ys) => e :: ys
      case (_, y :: ys) => y :: insertRecAt(e, n - 1, ys)
    }

  //P22
  def range[A](s: Int, e: Int): List[Int] = (s to e).toList

  //I don't think is the purpose of the exercise! Again, let's try recursion
  def rangeRec(s: Int, e: Int): List[Int] = if (e - s == 0) e :: Nil else s :: rangeRec(s + 1, e)

  //recursion and pattern matching with guards
  //a little more readable
  def rangeRecPm(s: Int, e: Int): List[Int] = (e - s) match {
    case x if (x > 0) => s :: rangeRecPm(s + 1, e)
    case x if (x == 0) => e :: Nil
    case _ => error("Invalid range")
  }

}


[EDIT: fixed problem 20 ]

Spare change at the whole Static-vs-Dynamic thingy

(NOTE: I'm a software developer, I have a blog, clearly I MUST write about static-vs-dynamic ... I guess soon I'll be writing a monads tutorial)

With all the fuss about Twitter migrating (the back-end) from Ruby to Scala (w00t!), the whole static-vs-dynamic debate has been re-ignited.
As a disclaimer, I'm in the static typing "camp". I've tried Ruby but didn't spark anything. In "dynamic languages", I have more experience with JavaScript (and for the record, I think is awesome: a true underdog of programming languages).
While I can appreciate the freedom and speed of development of dynamic languages, and I think is a matter of personal styles than about which one is better ("choose your own poison"), I think static typing suits better my frame of mind while creating software.
Anyhow, I felt something was missing in the debate and Twitter's use of "kind_of?" points to one of the reasons for static typing I been trying to articulate for a while.
(First and foremost: if you're going to complain "static typing forces me to add a lot of boilerplate and cruft", look into Haskell, ML, Scala, or F# and then come back or you'll force me to do evil things to cute creatures. And if you want to learn how a type system can be used to PROVE that a program is correct, look into Coq)

Types reduces the possible combinations between components
Any software program can be seen as a system of interconnected elements (modules/functions/objects, etc.), by adding type information you're restricting the ways those elements can connect to each other and the possible execution paths of the system. By doing that, you're loosing some of the valid combinations, you're also trimming many invalid ones.
The argument is with good unit tests you can check for the same things, but you have to actually write the code for that. While you should have unit tests for your module, without type restrictions, you have to write and test more execution paths. Moreover, writing the test, executing it and analyzing the result are separate steps, where your brain has to switch contexts.

Types as a Poka-Yoke
There's a lot of influence of Lean Manufacturing in software development (all the "Agile" stuff ), and from that perspective, having more restrictions on how you can use the available components acts like a poka-yoke mechanism: "a behavior-shaping constraint, or a method of preventing errors by putting limits on how an operation can be performed in order to force the correct completion of the operation". The same Lean / Total Quality Management recommends catching defects as early as possible and not use testing as a product quality measure. How more agile can you be when you don't have to write and run test to achieve a basic level of integration quality?

Types as (kind-of) contracts
By using static typing you get self-documenting self-enforcing operation contracts (for a price). I believe the larger and more complex the system, the more static typing can help than hinder your work.
NASA could have saved some money if they were able to write:

class MarsObiter {
def setThrust(v:Thrust[MetricUnits])= ...

There's no way you can use a Thrust[ImperialUnits] instead. (For extra points, you can define an implicit conversion in Scala :D )
But even if you have a basic type system like Java, don't just suffer it, use it at your advantage, create the types that can help you to write better code.
Check Stephan's excellent post on what do you loose if you use only primitive types with no semantic meaning (or no types at all)

Enough!
But enough babbling, I can show some examples using the "lowly" Java language:
Suppose we have a method to book a shipment for a customer and a container on a specific date.
Let's start without any typing information:


public bookShipment(customerId, containerId, shipmentDate){...


Totally valid, but... is "1234-321" a valid customerId? can I use a string as shipmentDate? in which format? What I get back?
Let's improve things a little by adding some basic typing information:


public boolean bookShipment(int customerId, int containerId, Date shipmentDate){...


Well, now I now that "X123Z" is not a valid customer or that "MRSK0023" is not a valid container, the date must be a proper date object, and it doesn't take a PhD to infer that will return true if the booking is successful.
But still, nothing prevents me to swap customerId with containerId and get a nasty but subtle bug. Wouldn't be nice if the compiler can prevent that? Well, it can if you don't use primitives and use more domain meaningful types, giving you a DDD flavor (and that's a win-win situation)


public boolean bookShipment(Customer customer, Container container, Date time){...


By examining the signature we know we can't pass a Container when a Customer is expected, and the method reflects better the domain of the application and tries to move towards "an ubiquitous language". But we can improve that:


public bookShipment(customer, container, shipmentDate) { ...


Here Hindley-Milner type inference takes care of identifying the input and output paremeters. No need to declare a thing and still type safe!
(although for documentation/readability purposes, I prefer explicit type declarations, and seems that the Haskell community agrees... that's why I don't mind typing the types of methods in Scala)



The whole point about all this? Go back and get things done, use whatever suites you best and don't waste your time reading blogs and stuff ;-)
If you excuse me, I need to step down from my tittle soapbox and go to do some coding...