by ·0 Comments

As I have been trying to learn more about Scala, there have been several paths that I’ve had to follow.  One is getting acquainted with the state of Java development, since ultimately Scala exists within the Java ecosystem.  Another is finding my way around the Scala libraries, tools, and idioms.  But there is a third that seems to be somewhat deeper, and that is coming to grips with the functional nature of the language.

Being a hybrid object-oriented/functional language means that for people used to imperative development, you can start with the idioms you already know, and add in the things you don’t.  In my case I’m really comfortable with OO programming, and I’ve gotten over the initial paradigm shift that C#/.Net 3.5 brought in with Lambdas, Closures, and Linq-style functional composition.  With that I could quickly latch on to some of the basics in Scala, like using the map method on a list to transform it, since it is effectively the same as select in C#.

Thing began to get a little shakier once I started digging deeper into some of the functional aspects of the language.  List Comprehensions in Scala took me rather off-guard until I realized that in .Net, list comprehensions are called “Linq queries”, though the syntax was still tripping me up.  I also started digging in to Higher Kinded Types aka Type Constructor Polymorphism, and in looking for examples inevitably I was led to more functional constructs.  Eventually I found myself looking at things like Functors, Monoids, and the dreaded Monad. The problem I ran into, though, was that for the most part, these concepts were described in the various blogs in terms of their equivalents from purely functional languages, and the most often cited purely functional language was Haskell.

Clearly the only way I was really going to understand these concepts was to learn Haskell….if nothing else I needed to at least be able to understand those crazy type signatures with all of their arrows pointing all over the place. Almost against my own will I’ve been forced to read a lot about Haskell, and to be honest I’m really glad that I did.

As strange as functional concepts are when coupled with the already familiar Object Oriented world, getting your head around a purely functional language is harder.  You have to forget about things like “classes” for containing data, and encapsulation within objects, not to mention polymorphism via sub-classes (or interfaces).  The concepts of encapsulation and polymorphism still exist in Haskell, they’re just different.  More importantly there are elements of the language that are brilliantly simple and elegant (at least to me).  The default style seems to be taking small pieces of functionality, and composing them to make something that is powerful (something of the holy grail in the OO space).  The downside to this is that you can have very small segments of code which are extremely dense, and as a noob it’s difficult to understand why some things happen in the way they do.  But things are getting easier with more exposure.

At this point I’m wanting to really grok the language and the idioms used to build software in a purely functional way, and I’ve gone well beyond just learning enough to understand references in blog posts about Scala.  As such I’ve set myself a goal of completing a project in Haskell that I’m keeping under my hat for the time being…mostly because I don’t know that I’ll ever actually finish it.  One of the more interesting aspect of this for me is the fact that I really don’t know where to begin to build something in Haskell.  Normally I would start thinking about objects and relationships, and that doesn’t apply here.  It’s an interesting state to be in.

So now the question is “do I abandon Scala/C#/Wahtever?”  Of course not.  As impressive and powerful as Haskell is (and trust me, it is a lot of both), and in spite of the fact that there are native compilers for every platform known to man (more or less), and the libraries available are extensive, it doesn’t seem to have a huge footprint.  It’s kind of a shame, since there are things like STM and compile-time parallelization (yes, that’s right), and seems like a good fit distributed computing in general.  For now I’ll let it open the door to new and different ways of solving problems….and maybe eventually see if I can sneak something small into production.

by ·0 Comments

Continuing our journey down the path from the familiar to the down-right bizarre, we find ourselves at Pattern Matching.  This is a feature of the Scala language that shows it’s functional side in a strong way.  Pattern Matching is a fundamental part of functional languages in general, and provides a way to write very concise and expressive code.  On the surface, pattern matching in Scala looks an awful lot like switch statements in C# (and Java for that matter), but you shouldn’t cling too hard to that association.

The Basics

Let’s start with a basic example that mimics the behavior of a switch statement.  Here is a quick sample entered directly into the Scala interpreter:

scala> val x = "Hi"
x: java.lang.String = Hi
scala> x match {
     | case "Hi" => "Hi yourself"
     | case "Ho" => "Am Not!"
     | case _ => "What?"
     | }
res1: java.lang.String = Hi yourself

Yes, this looks really boring…but the syntax should be clear. The Pattern Match is invoked using the match keyword, followed by a block containing case expressions. It’s worth pointing out at this point that the match is an expression, which means it has a value when evaluated (which is why the result from the interpreter is a string, and we don’t have/need any return statements). This means that the results of the match can be assigned to a variable, or used as the return value of a function. The case statements in this example are simple, they match against string literals. The exception being the last, which uses the special wildcard match expression _.  As may be expected, evaluation happens in order, and the first expression which contains a matching pattern is the one that is executed.  Had the previous example placed the wildcard pattern first, then that would be evaluated every time, regardless of what value is passed in.

Now if this is all you could do with Pattern Matching, it wouldn’t be all that interesting, and I probably wouldn’t be sharing it with you.  The cool thing about Pattern Matching expressions is that you are not limited to literals or enum values like you are with C#.  One of the things you can do is match based on type:

x match {
    case x:String  => "You gave me a string: "+x
    case x:Int     => "You gave me a number: "+x.toString
    case x:MyThing => "You gave me some thing: "+x.toStirng

A contrived example to be sure, but as you can see it is really easy to handle different types using the standard Scala type notations.  The return value of the match expression will be the most specific type that is the result of all possible expressions.  You need to be a little careful with this, since if a match expression appears at the end of a function, then the function’s return value will be the same as the match expressions.

Deconstruction

Now, type based matching is pretty cool, and honestly I’ve wished for this kind of functionality in C# before, but there is more.  One of the primary uses for Pattern Matching in purely functional is for deconstruction of data structures.  By this I mean extracting values from data structures so you can use the data elements directly.  A quick example using a basic tuple would look like:

x match {
    case (y,z) => "A tuple with "+y+" and "+z
    case _     => "Something else"
}

If x is a tuple, then this expression will print the values of both elements. The pattern (in this case (y,z)) binds the variable y to the first element in the tuple, and z to the second. If, for example, you didn’t care about the value of the second element in the tuple, then you could use the wildcard character in the pattern:

x match {
    case (y,_) => "The first element from the tuple is "+y
    case _     => "Something else"
}

A common use for Pattern Matching in functional languages is to split a list into it’s head (fist element) and tail (every other element). You can do this in Scala with a pattern that looks like:

list match {
    case Nil      => "Empty list"
    case x :: Nil => "Single element list: "+x
    case x :: xs  => "List has a head of "+x +" and tail: "+xs.map(_.toString).reduce(_ + ","+ _)
    case _        => "Not a list"
}

Looking at the patterns here, we have some interesting options. The first matches agains Nil, which is an empty list. The second uses the pattern x :: Nil, which is a list with a single element (and binds that element to x). The next pattern x :: xs divides the list into head (bound to x) and tail (bound to xs) segments. These are the standard three types of matches you see when pattern matching against lists.

Extractors

This ability to deconstruct objects is not limited to standard built-in types.  Scala has a generalized pattern called Extractor Objects which provide a way to create objects that can be used in Pattern Matching.  Lets put together another cheesy example to demonstrate this:

class MyThing(val one:Int, val two:String)

object MyThing {
    def apply(thing1:Int,thing2:String) = {
        new MyThing(thing1,thing2)
    }
    
    def unapply(x:MyThing):Option[(Int,String)] = {
        Some(x.one,x.two)
    }
}

val m = MyThing(2,"one")

m match {
    case MyThing(y,z) => "MyThing with two items: "+y+" and "+z
    case _            => "Not a MyThing"
}

For sake of completeness I’ve included the apply method, which (you may recall) is how you create objects in Scala. It also provides some context for the unapply method so things are a little less confusing  Since Pattern Matching performs deconstruction, it seems only logical that the method that does this work is called unapply. This method may look a little funny, but basically this is what happens. The item you are doing the match against is passed into the unapply method. If the method returns a Some value, then that is the expression that is evaluated, otherwise it moves on to the next. Also, if the item doesn’t match the type of the argument to the unapply method, then it will skip that expression. If you’re unapply returns a Some[x] then that value gets bound to the variables. In this case we have two, so we’re returning them in a tuple.

Case Classes

Now, this is cool, but there is a lot of typing involved. Scala has a handy-dandy short-cut for doing this sort of thing called Case Classes. A Case Class allows you to define a basic class, and it automatically adds the companion object type with apply and unapply methods, along with accessesors for any constructor arguments. So, using Case Classes we can rewrite the previous example as:

case class MyThing(one:Int, two:String)

val m = MyThing(2,"one")

m match {
    case MyThing(y,z) => "MyThing with two items: "+y+" and "+z
    case _            => "Not a MyThing"
}

As you can see, this removed the need for the companion object all together. Granted, all of the code is still there after the magic from the compiler, but there is way less typing involved.

Guards

As if Pattern Matching wasn’t cool enough, you can further refine results from the match using Guards. This basically gives you a way to add additional conditions to a pattern using standard expressions which evaluate to a bool. Building on our previous example, we can do some more complex matching on the individual properties of the object within the pattern. It looks something like this:

x match {
    case MyThing(y,z) if y > 10 => "MyThing.one is more than 10"
    case MyThing(y,z) if y > 5  => "MyThing.one is more than 5"
    case _                      => "MyThing doesn't meet criteria"
}

The if right after the pattern defines the guard. You can use standard boolean operators like || or && as well, but the more complex things get the less readable things tend to be.

Hopefully I’ve given at least a little glimpse into the coolness of Pattern Matching in Scala.  The coolness of patterns is used in several different places in the language, including in the Regular Expression library, which gives a really easy way to check against regex matches, and extract elements from the regex if that’s the sort of thing you’re into.  We’ll be seeing more Pattern Matching as we start delving into more functional aspects of Scala.  Hopefully you’ll be able to appreciate the elegance and simplicity it can provide.

by ·0 Comments

This is part 3 in a series.  If you’ve not followed-along so far, you may want to check out Part 1 and Part 2 first.

It’s time to start digging in to some of the crazy-goodness that makes Scala such a glorious and wonderful thing.  First things first, though, we have to talk a little bit about this history of Generics in Java and the JVM. 

 

 

Type Erasure and you…

Back around the time that .Net was adding support for generics, the folks in Java land were doing the same…sort of.  The biggest difference between the way Generics were implemented in .Net and Java is the fact that in .Net generics are supported directly in the CLR (sometimes called reified generics), whereas the JVM did not include direct support for generics.  Ok, so what does that actually mean?  Well, for starters it means that when you’re dealing with Generics in Java you run into Type Erasure.  Type Erasure means that when Java code with generics are compiled, the generic type information is removed at compile time, so while you’re looking at an ArrayList<String> in Java, the JVM sees this as just an ArrayList, and things get cast as needed.  There are a couple of types which get reified into actual types (Arrays are the best example), but for the most part this doesn’t happen.  In contrast in the .Net world a List<string> gets compiled into a List`1<System.String> which is a real type at the IL level.  Now, I’m not going to get into the argument about whether or not type erasure is good or bad, but it is a fundamental difference between the two platforms. 

One very interesting effect of Type Erasure is that it allows you to specify a wildcard type argument for a generic type parameter.  In Java this looks something like ArrayList<?>, in Scala this same type would be ArrayList[_].  Now, this is interesting because it allows you to side-step the whole issue of providing type arguments when you really don’t care what they are.  Now, lets back up one step real quick and talk about syntax for a moment. 

Getting down to business…

Those of you with sharp eyes will have noticed that Scala uses square brackets for type arguments.  You can limit types (in a way similar to generic constraints in C#) based on other types by using the following syntax: MyType[T <: AnyRef].  In this case we’re saying the Type argument T is a subtype of AnyRef (which you may recall is the supertype for all classes).  This is known as a Type Bound, and specifically in this case an Upper Type Bound.  You could speculate (and would be correct to do so) that a Lower Type Bound works in the opposite direction, so MyType[T >: A] means T is a supertype of A.  Now, this is interesting from a theoretical perspective, but there are practical uses for this when you bring in covariant and contravariant type parameters.  Scala allows you to denote a covariant type like this: MyType[+T], and a contravariant type like this: MyType[-T].  These are equivalent to the .Net 4 variance modifiers in and out.  So the .Net version of our MyType declarations would be IMyType<in T> and IMyType<out T> respectively.  Note I added the I to the type names since in .Net type variance declarations are limited to interfaces and methods.  This limitation does not exist in Scala, so you’re free to add variance modifiers wherever you like.  Ok, so why do I say type variance becomes interesting when you combine it with type bounds?  Well, lets look at some real live Scala code and see:

sealed abstract class Option[+A] extends Product {
...
  def getOrElse[B &gt;: A](default: =&gt; B): B = 
    if (isEmpty) default else this.get
...
}

So this is a chunk of code from the Scala library. This is a sample of the Option class, which is an implementation of the Null Object Pattern, that is used everywhere within the Scala libraries. If you look at the type declaration you can see that Option takes a single type parameter A that happens to be covariant. This is because when you have an Option of a specific type you expect to be able to get that type back out of it. However, there is also this getOrElse method, which will either return the item, or return the value of the function you pass in (which should return the type A). Now if you were to try and make the argument to the function something like => A you would get a compiler error because a covariant type is appearing in a contrvariant position. This happens in C# as well, if you were to do the same thing. So the solution to this is to give the getOrElse method a TypeParameter, and specify a lower bound of A, which means B has to be a supertype (or the same type as) A.  This is particularly awesome since we would like that to be a contravariant operation anyway.  This is a very nice trick, and one I wish it were possible to use in C#.

Types of Types of Types…..

But the goodness does not stop there.  We’re going to head off into the land where Scala really asserts itself in terms of it’s type system.  In Scala it is possible to specify that the Type Parameter of your class/method/whatever should itself also have a type parameter (which could also have a type parameter, that could have a type parameter….you get the idea).  This is known as Higher Kinded Types (from the idea of Higher Order Functions in Functional Programing, which are functions that take functions as arguments).  A Kind in type theory is basically a higher-level abstraction over types which relates to types in basically the same way types relate to variables in terms of regular code (I know this didn’t actually help explain anything, but it sounds good right?).

You may be wondering why this is a big deal, or even what use it may have….well, lets turn to another example from the Scala library.  In this case we’re going to talk about the Map function that exists on pretty much every Scala collection (or collection-like) object.  This is a method that allows you to take a collection of one type, and turn it in to a collection of a different type…more or less equivalent to the Select() method from Linq on IEnumerable.  Now, what is really cool about the Scala Map method is that when you call it on a List<y> for example, and pass it a function to transform y into x,  you will get back a List<x>.  The important part here is the fact that it is a List…not an Iterable, not an Enumerable, not any other supertype in the heirarchy, but a List.  And to top it all off this method is defined at the top level of the Collections type hierarchy.  So if you create a new collection that inherits from one of the existing collection types, you get a Map method that behaves the right way free of charge.  This is impossible to do in C# without creating an implementation of the method for each object (and if you did that you would have no contract at the IList or IEnumerable level for the method).  I’ll let that sink in for a moment.  Now, there is a lot of very cool things going on in the type system which will get their own posts (or twenty) at some point, as a matter of fact Scala’s type system is actually Turing Complete in and of iteself, which makes my head hurt to thing about. But apart from that there is one more thing I want to share about Scala’s type parameters before wrapping this up.

A quacking all the way…..

In addition to specifying type arguments as parameters, you can actually get more granular and tell Scala you’ll take any object it’s got as a parameter, as long as it has some specific method declaration(s).  This is effectively duck typing, and makes testing really, really easy when you can use it.  The syntax for doing this looks like:

def MyMethod(thing: { def that(x:Int) }) = thing.that(2)

Take a long look at that for a sec, let it sync in.  Now, this is pretty good stuff by itself, but Scala’s type system gives us even more goodness.  One of the nifty things you can do is declare new types in terms of other types.  Something like aliasing….but with a lot more power, particularly when you take into account the fact that you can use the same “duck typing” syntax to define a type.  So here is what that would look like:

class Test {
    type Dog: { def bark; }

    def itBarks(dog:Dog) = dog.bark
}

class Wolf {

    def bark = println("Actually, I tend to howl more")

}

class Poodle {

    def bark = prinln("Le bark, Le bark")
}

val test = new Test()
test.itBarks(new Wolf())
test.itBarks(new Poodle())

So, as you can see, you can use type definitions as a form of shorthand for the duck-typed references. What’s even cooler is that you can actually define types at a package level as well, which means you can define them once in your project, and use them wherever you need them. This is something like the using aliases you can set up at the file level, only you can declare them at a much broader level. As a matter of fact, Scala has a special file called Predef that gets run before anything else in a Scala program. This file defines a lot of nifty things, like the println method, including several types that can be used in any Scala program (check our the source if you’d like). Pretty groovy, no?