f<*> yea, scala!

ugly flatMap {sweeeeet _}

[fuckyeascala-blog]

Holy Carp, Pattern Matching - pt 2

Last time we saw the basics of how pattern matching works. If the thing that we're matching is the thing in the case statement, then magic happens. However, that alone doesn't make pattern matching super badass. Advanced decomposition and recursion are really where pattern matching shines, because it lets us do wonderful things on the collections we build with much less fiddliness.

Patterns, decomposition, recursion, oh my!

We’ve put together some handy tools already. Actually, we’ve already got the ability to put together some pretty wicked functions. Remember when we looked at lists in the earlier posts? We used a method called head to get the first element of the List. With recursion and pattern matching, it’s trivial to recrate this:

def head[A](l:List[A]) = l match { case Nil => throw new NoSuchElementException("head of empty list") case h :: _ => h } scala> head(List(1,2,3)) res7: Int = 1

WHHAHAHHAATT???! Yup. Remember how I showed you early on that a List is really just a bunch of things strung together by :: until you hit a Nil and you were probably thinking I was crazy at the time. Now you see why! In the same way as we can decompose a tuple we can decompose other data structures too.

We also threw and exception. If you don’t know what that is, it’s an error that blows up and stops your program. You should probably already know what that is though. Speaking of blowing up though, is our match safe to use here? Will we get a MatchError? Well, the first case matches Nil (another way of saying List()), and patterns are matched in order, so if we get past that case, we know that are List is not empty. Therefore, the second case must match, as it is some element followed by anything else, even if that “anything else” is an empty List. This pattern is the same we employed above, where the case that could cause a recursive funtion to end or act abnormally is handled first, and is generally known as a “base case” or a “stopping condition”.

Decomposing All Over

Decomposition isn’t limited to case statements. You can actually do it in all kinds of places where you might match something, even outside a match statement. Scala calls these “extractor objects”. The details of this involve some machinery much deeper than we care about, so we won’t go into why this works too thoroughly. Instead, just remember that if you want to break something down smaller, there’s a good change you can. Take a look at how we can run through this list of tuples and sum them inside of a for comprehension:

scala> List((1, 2), (3, 4), (5, 6)) res3: List[(Int, Int)] = List((1,2), (3,4), (5,6)) scala> for ((x,y) <- res3) yield x+y res4: List[Int] = List(3, 7, 11)

So, next time you think you could use a value better if it were broken down into its components, give it a shot! There’s a good chance you can decompose it wherever you are. Decomposition everywhere, it’s like a zombie invasion!

Aliases

Want your cake and to eat it too, huh? I knew you were the greedy type. Have no fear, the as-pattern is here. What’s it do? Well, it lets you both deconstruct the case match and have a reference to the whole thing. It involves using the @ sign before a pattern and looks like this:

scala> (1, "hurray!") match { case w@(i:Int, s:String) => w + " is made of a " + i + " and a " + s } res0: String = (1,hurray!) is made of a 1 and a hurray!

This is an often-skipped pattern in introductory texts because frequently, you’ll have a reference to the thing you’re decontructing in scope, and you can achieve the same by decontructing your object manually in the case body. However, this is prettier, and we haven’t found a reason to use an @ sign anywhere else in the blog yet, so that key was getting lonely and needed some love.

Sound the alarm!

Quickly! Summon the guards! Why? They let us combine the power of match statements with full-fledged conditionals. This takes our match from super-powerful to overwhelmingly cool. Guards let us reduce having a bunch of hairy nested if statements and whatnot which make our code harder to read.

Maybe you walk around all day with your FatButt personal pedometer all day and you want a function to degrade or reward you based on your taking enough steps in a given day. You could write your function like this:

def mySteps(steps:Int) = if (steps < 2500) "you aren't even trying" else if (steps < 5000) "that is pitiful" else if (steps < 7500) "ok but still walk more" else "hey you walked. good for you."

With guards, that looks a little like this:

def mySteps(steps:Int) = steps match { case s if (s < 2500) => "you aren't even trying" case s if (s < 5000) => "that is pitiful" case s if (s < 7500) => "ok but still walk more" case _ => "hey you walked. good for you." }

Ok, perhaps that isn’t particularly convincing. It looks like just as much code as before! You must admit it’s pretty fun to type those rockets though. What if you had to look for your fitbit data inside an object though?

def mySteps(t:(String, Int)) = if(t._1 == "fatbutt" && t._2 < 2500) "you aren't even trying" else if(t._1 == "fatbutt" && t._2 < 5000) "that is pitiful" else if(t._1 == "fatbutt" && t._2 < 7500) "ok but still walk more" else if(t._1 == "fatbutt") "hey you walked. good for you." else "What the heck is a " + t._1 + "?"

Which is pretty gross. Or perhaps you get really fancy and write something like:

def mySteps(t:(String, Int)) = { val device: String = t._1 if (device == "fatbutt") { val steps: Int = t._2 if (steps < 2500) "you aren't even trying" else if (steps < 5000) "that is pitiful" else if (steps < 7500) "ok but still walk more" else "hey you walked. good for you." } else "What the heck is a " + device + "?" }

With a guard though, matching the new object is pretty trivial.

def mySteps(t:(String, Int)) = t match { case ("fatbutt", s) if (s < 2500) => "you aren't even trying" case ("fatbutt", s) if (s < 5000) => "that is pitiful" case ("fatbutt", s) if (s < 7500) => "ok but still walk more" case ("fatbutt", _) => "hey you walked. good for you." case (s, _) => "What the heck is an " + s + "?" }

As you can probably see, adding a guard to a case statement is as easy as putting an if statement after the case match condition. Any variables you bind in the decomposing in the case statement are available to test against. Talk about power!

[fuckyeascala-blog]

Holy Carp, Pattern Matching - pt 1

We know enough about the type system to get what we need into our functions. However, the type system probably seems a bit opaque. Why would we even want to deal with really complex types? Well, it turns out the type system can do a lot for us when put to use properly. With a type system as strong as Scala’s, it’s shouldn’t be surprising that there’s support built right into the language for making decisions based on the type and contents of your values! So, the next few posts are dedicated to getting a grasp on one of Scala’s most powerful features, pattern matching.

Pattern Matching!

Pattern matching is the ability to discern which textiles appear most visually appealing together. However, we’re talking about Scala, where pattern matching involves Scala’s ability to deconstruct types and values so that we can make decisions based on those structures. That’s even cooler than plaid golf pants!

The powerhouse behind Scala’s pattern matching system is the unsurprisingly named match keyword. What’s it do? Well, it combines decomposition, conditional execution and type-casting all into one thing. That might sound like a lot, but if you think about it, chances are you do these things together quite often in lesser programming language. Scala gives us this all in one easy-to-use package:

scala> def magicNumber(n: Int) = n match { case 3 => "IT'S THE MAGIC NUMBER!" case _ => "just an ordinary number" } magicNumber: (n: Int)String scala> magicNumber(4) res0: String = just an ordinary number scala> magicNumber(5) res1: String = just an ordinary number scala> magicNumber(3) res2: String = IT'S THE MAGIC NUMBER!

Hopefully it’s pretty easy to see how this quick example works. Calling magicNumber uses the match keyword on whatever we pass in as n. The match consists of a list of cases to check the value n against. Scala then checks each of these cases from top to bottom asking “Does this thing match what I’ve been asked to match against?” Scala can check for a bunch of different kinds of matches, based on the type, value, or decomposition that you provide. Here we’ve only got two cases, one for the value of 3, and the other might look weird – an _! Yes, an _ in a match is a wild card. Think of it like a fill-in-the-blank. If we see anything other than the value 3, it’s just an ordinary number.

Why do we want the wild card? If Scala doesn’t find a match, it will throw a MatchError:

scala> def failMatch(a: Any) = a match { case _:Int => "int!" } failMatch: (a: Any)String scala> failMatch(1) res3: String = int! scala> failMatch(5.5) scala.MatchError: 5.5 (of class java.lang.Double) // …

Notice here, that I’ve sneakily introduced that we can match things based on the type. Just like we’d declare a the type of a var or a var, we can add a type annotation to a match case to only match that case if the type is the same. Therefore, _:Int does match any value (because of the underscore) but only if that value matches the type Int!

I bet you can guess already: this kind of conditional makes our code safer, since it a) guarantees that there will be some value as a result of the match statement and b) ensures that if we don’t cover all possible results of the value we’re looking for that we will get a nice big loud error.

That’s pretty cool, but what about if we wanted to use the value – can we do that? You betcha! Let’s expand our magicNumber function to tell us more about the number we did get:

scala> def magicNumber(n: Int) = n match { case 3 => "IT'S THE MAGIC NUMBER!" case x => x + " is just an ordinary number" } magicNumber: (n: Int)String scala> magicNumber(3) res5: String = IT'S THE MAGIC NUMBER! scala> magicNumber(436782) res6: String = 436782 is just an ordinary number

What’s this guy do? Well, it shows that we can actually pick out the value and assign a name to it in our case statement. The body of the case (to the right of the =>) gets the value of the match named as x. Here, we could have used n just as easily, but that wouldn’t have demonstrated anything!

Let’s look at a practical example: How can we easily find a triangular number with a base size of n? Well, a triangular number is the sum of all the natural numbers from 1 up to n, which we could restate as the sum of all the natural numbers from n down to 1.

scala> def triangular(n: Int):Int = n match { case 1 => 1 case x => x + triangular(x - 1) } triangular: (n: Int)Int scala> triangular(10) res0: Int = 55 scala> triangular(32843) res1: Int = 539347746

First of all, as you can probably tell, this is one of those recursive functions we’ve been talking about. A function is considered to be recursive if it calls itself. Chances are, you probably knew that already, so we’re not going to dwell on it. Instead, let’s look at what we’ve defined here: we have stated that the triangular number of 1 is 1, or for any other integer, the triangular number of that integer is that integer plus the triangular number of the previous integer. That’s really simple! We will see this pattern a lot when combining recursion and pattern matching, so don’t worry about absorbing it too thoroughly yet, we’ve got a lot more pattern matching to cover!

Basic Decomposition

We’ve seen how pattern matching gives us conditional exexution and casting, which is fine and dandy since I’ve certainly typed enough “if” and (int*) statements in my day. Pattern matching really shines though when you start combining those with it’s ability to decompose more complex types. For now, we can keep it simple and use our good friend from a few posts ago, the tuple!

When we pass some kind of structured type to a match statement, we can use variables within the type in our case match. So, if we wanted to get the two parts of our tuple out as separate variables, we can do that:

("first", "second") match { case (f, s) => f + " is first and second comes " + s }

The () in our case statement matches with the parenthesis around our tuple, and the f and s match the strings on the inside. Therefore, in the case body, f will be assigned the first element of the tuple, with s getting the second. I happen to think that’s quite pretty!

Suppose you wanted to add two vectors in you whizbang new 2D game. How you wrote a 2D game between since you started reading this blog is beyond me, but that’s not the point. Since you surely wrote your 2D coordinates as tuples, you almost certainly wrote something like this for your vectorAdd function:

scala> def vectorAdd(first: (Int, Int), second: (Int, Int)) = (first._1 + second._1, first._2 + second._2) vectorAdd: (first: (Int, Int), second: (Int, Int))(Int, Int) scala> vectorAdd((3,0), (1,4)) res0: (Int, Int) = (4,4)

That works fine and all, but you could be using pattern matching to actually decompose your tuples!

scala> def vectorAdd(first: (Int, Int), second: (Int, Int)) = (first, second) match { case ((x1, y1), (x2, y2)) => (x1+x2, y1+y2) } vectorAdd: (first: (Int, Int), second: (Int, Int))(Int, Int) scala> vectorAdd((3,0), (1,4)) res1: (Int, Int) = (4,4)

This might look confusing at first because of all the parenthesis, but let’s take a look at it from what we already know. We initially create a tuple of our first and second tuples, but this is only to set up a single pattern that’s easy to match with a single case statement. Then, if we look closely at our case statement, it matches a tuple containing two tuples each of two elements each. Inside each of those, we can place variables for the elements which we’d like to use in the case body, and voila! The appropriate tuple elements are extracted automatically with very little effort on our part. This type of decomposition will work with structures of types much more complicated than you’re probably willing to deal with as well.

Notice we don’t have a catch-all here either. We’ve written our function in a way that it is impossible to not match against the argument of the function, so it’s not necessary! Good job, type system – thanks for the help!

Next time around, we'll go through how to match up this powerful new feature with things like recursion and decomposition which make it seem like a first-rate powerhouse that will totally rip your programming face off.

[fuckyeascala-blog]

Let's talk about types, pt 2

Papers, please! Do you have any types to declare?! Let's jump right in and talk about what the annotations attached to Scala's types look like.

Type Annotations and Declarations

Luckily though, we don’t need to depend on inference, and instead, we can be explicit in telling Scala what types we’d like, which is generally considered a best practice. We do this with type declarations! Type declarations are the annotations we’ve been seeing in the REPL between the reference’s name and the value that it has.

scala> val x = 1 x: Int = 1 scala> :t x Int

When we declare the value x is 1, the REPL immediately shows us the name of the reference (x), followed by a colon (:), and then the type (Int) - x: Int. This is called a type annotation. The colon means “is of the type”, so this can be read “x is of the type Int”.

That’s not the only type annotation we’ve seen though. We also know that the type annotations functions look a little wonky. Let’s take a look back to when we defined our very first functions!

scala> val addAnotherOne = (x:Int) => x + 1 addAnotherOne: Int => Int = <function1>

Remember that guy? Yea, I barely do too. That’s ok though, because due to the type annotation, I can see right off the bat that addAnotherOne has the type Int => Int. You’re reading that right, it’s actually a single type, and the => is an annotation for function objects that mean “and returns”. So, we could read this as “addAnotherOne is a function that takes an Int and returns an Int”. This isn’t the same for defined methods though, which look like this:

scala> def revMe(s: String) = s.reverse revMe: (s: String)String

This one has a declaration that looks like (s: String)String, which is a lot like the previous definition, but instead of using an arrow, it simply has the return type after the list of parameters. There are reasons why this is so, but I’ll take the author’s privilege of not telling them to you, because I think they are boring.

These are kind of important so let’s review a few more:

scala> def thereAndBack(t: String, b: String) = t + b.reverse thereAndBack: (t: String, b: String)String

Can you read that type annotation yet? Go ahead and try, I’ll wait. Ok good, did you get something like “thereAndBack is a method that takes a String t and a String b and returns a String”? If so, you’re doing well! Let’s try it a little differently:

val thereAndBack = (t: String, b: String) => t + b.reverse thereAndBack: (String, String) => String = <function2>

What do you think? How about “thereAndBack is a function that takes two Strings and returns a String”? Ok last one:

scala> def foo(f: Int => String => Boolean => Double) = f.apply(5) foo: (f: Int => (String => (Boolean => Double)))String => (Boolean => Double)

If you said “foo is a function that takes a function which takes an Int and in turn returns a function that takes a String which then returns a function that takes an Int which returns a Double, and then from that returns a function that takes a String which returns a function that takes a Boolean and returns a Double” you should go buy yourself a chocolate sundae as a reward for being totally awesome.

Since we have type annotations, it’s possible to tell Scala that we’d like a value or variable or function to be of a particular type. Technically, this is called a “type ascription”, but that’s a term that I usually forget (I had to go look it up again to write this sentence), so I will usually just call them “type declarations”. They look much like type annotations (because they are) just placed right after our reference’s name:

scala> val poo:String = "the bear, of course!" poo: String = the bear, of course!

Here, we have declared a value referred to as “poo”, which is of type String. Simple, compared to all the work we just did in reading type annotations!

Earlier, when we were messing around with inference, we saw that Scala can sometimes infer a type other than the one we meant and pick a parent type that also matches. If you wanted, you could actually declare poo to be of any of its parent types:

scala> val poo:Any = "the bear, of course!" poo: Any = the bear, of course!

However, this means that Scala will treat it as a member of that type instead, and it will not have any of its magical functionality that might be part of the same value if were declared to be of a more specific type.

scala> poo.reverse <console>:9: error: value reverse is not a member of Any poo.reverse ^

Despite the official Scala style guide stating “use type inference where possible”, declaring what type you intend some value to be wherever you think you know what it should be will maximize the number of places the Scala compiler can catch your mistakes, and therefore let you take full advantage of Scala’s strong, static type system. Therefore, I’ll actually recommend the opposite, and you should go ahead and declare types wherever you can. Type away![1]

Hopefully by now, you’ve already absorbed most of what declaring types in function definitions is like, as we’ve done it a few times in this and preceding posts. Each parameter in the argument list gets a type annotation (otherwise how would Scala know what kind of objects you should pass to the function, and therefore how to type-check it for you), and optionally, we can put a type annotation after the parameter list to show the return type that we’ll get from the body of the function.

scala> def addTwoToTwoAndSum(x:Int, y:Int) = (x + 2) + (y + 2) addTwoToTwoAndSum: (x: Int, y: Int)Int scala> def addTwoToTwoAndSum(x:Int, y:Int):Int = (x + 2) + (y + 2) addTwoToTwoAndSum: (x: Int, y: Int)Int

Again, while the official style guide recommends inference where possible, I say that it’s safer for the compiler and better for you learning if you just put in the types explicitly all the time anyways. I know that might cause some cognitive dissonance, but if you’re not clear on what type a function or value should be, remember you can always test it out in the REPL, which will gladly tell you what type it thinks your code is, so you can make a decision if that’s really what you want.

Type Parameters

We’ve already explored some situations where the type of a thing might not be known when we define it. Instead, we might want to declare that it works with multiple types. The List type we talked in the before is a good example. We can have lists of Int, lists of String and so on. This is very common with collections or other abstractions that might apply to a number of different types, and in some other language that we will ignore but you might know, they’re called “generics”.

scala> val a = List(1, 2, 3) a: List[Int] = List(1, 2, 3)

Here, we’ve declared a List, but not just any List – Scala has correctly inferred that we would like a List[Int] – that is, a List of Int objects, which can simply be read as “List of Int”. You’re right in assuming that the square brackets denote a parameterized type, if that’s what you’ve done!

Why might this come in handy? Well, let’s take the example of lists. Certainly, we’ve already seen that you can make lists of all kinds of things. List is happy to hold whatever type of thing you’d like! Do you think someone went around and defined a function for every type of list you’d like to create? No, that would be preposterous! Instead, they’ve used a type parameter. Type parameters let us write functions and types in a type-safe way without needing to define the specific way they work with each type, but rather the rules governing the relationships of our types.

Let’s say you’ve got a collection of things – an immutable collection of things, even. Due to some wizardry up the class tree from your collection, someone has defined a method that turns it into a list.

scala> (1 to 5).toList res5: List[Int] = List(1, 2, 3, 4, 5) scala> Set('a', 'b', 'c').toList res6: List[Char] = List(a, b, c)

Now, that toList function has a type signature of def toList: List[A]. Where does the A come from though? Well, the types of Range and Set include [A] annotations in their definitions, so when you create a Set of some type (like Char), when you go to convert it to a List, Scala knows that list should be filled in with the appropriate type of A (Char, in this case), and we get a List[Char]

This is really powerful, but we won’t get into it a whole lot until we start defining our own types. However, if we wanted to write our own function that made a List of things based on a type parameter, we could write something like this trivial little tidbit:

scala> def gimmeThreeOf[A](x: A):List[A] = List(x, x, x) gimmeThreeOf: [A](x: A)List[A] scala> gimmeThreeOf(5) res7: List[Int] = List(5, 5, 5) scala> gimmeThreeOf('r') res8: List[Char] = List(r, r, r)

Here we define a function with a parameterized type A. That type is going to be the type of whatever we send in for x. Then, we’re going to have a list of that type! The [A] means that A is going to be a type parameter, and it tells Scala: “Hey, when you can figure out what type to make A” – by passing it an Int, let’s say – “go ahead and fill in all the other As with that type”.

Scala includes lots of other annotations for parameterized types that let you restrict whether it can take only subtypes or parent types or only to allow types that can be automatically converted to other types, and so on. There's a lost of material and reasoning and so forth surrounding that whole thinger, so we'll have to get to that much, much farther down the line. Instead, we'll take up the torch of something badass on the next one – pattern matching! It might even help you figure out that 1,000 piece jigsaw puzzle…

Get it, ’cause it means you have to type more?! … I’ll see myself out.  ↩

[fuckyeascala-blog]

Let's talk about types, pt 1

Now finally, we come to one of the topics surrounding Scala that makes it so badass, which is the type system it uses. We already discussed briefly that Scala is strongly typed – everything in Scala has a type. That type is also known when we compile our program, which means that Scala is also statically typed. Because Scala knows the types of everything at compile time, it can catch all kinds of errors that other languages can’t! That’s pretty cool.

Type-safety

Well if Scala can find common type errors for us, what exactly do those errors look like? Well, some languages (and we won’t point fingers) will let you do silly things like make a variable an Int and then later make it a String. I guess that’s fine if you’re a really good and smart programmer who can keep track of what methods the variable you made has based on the type of object it is right now, but I’m a bad and dumb programmer, so when I go to call + on my (formerly) Int to add another number to it, I will be sorely disappointed with the results!

> var a = 5 undefined > a 5 > a + 12 17 > a = "what is this i don't even" 'what is this i don\'t even' > a + 12 'what is this i don\'t even12'

Well that is not what I wanted at all! Compiler, why would you do this to me?! What have I done to upset you?

Scala, on the other hand, allows no such nonsense[1]. In Scala, pretty much everything is type-safe, meaning it won’t let something attempt to be a thing that it isn’t! If I declare a variable of 5 in Scala, it will have the Int type. Now, despite declaring that as a var so its value could actually change to something other than 5, the type of that variable will always be Int! If I try to change that variable to anything other than a new Int, Scala will refuse to compile it with great vengance.

scala> var a = 5 a: Int = 5 scala> a = "i think it's going to break" <console>:8: error: type mismatch; found : String("i think it\'s going to break") required: Int a = "i think it's going to break" ^

That’s Scala’s way of saying “You sir, have attempted to use a String where I require an Int, and are you sure you know what you’re doing?”

Type Inference

When I tell Scala “Hey buddy, just to let you know, var a = 5”, it knows I want an Int. Well actually, it infers that I want an Int, so that had better be what I wanted. You see, Scala has some smart guys who decided that a constant number typed into the code that wasn’t followed by a . and some more numbers and isn’t particularly large is probably an Int. It does this because as I mentioned before, everything in Scala must have a type, and if Scala is going to support saying var a = and then something after that, it must have some mechanism for supporting such wishy-washy declarations. For the most part with simple decisions like this, Scala does a really good job!

scala> var b = 5.0 b: Double = 5.0 scala> var c = "5" c: String = 5 scala> var d = '5' d: Char = 5 scala> var e = true e: Boolean = true scala> var f = null f: Null = null scala> var g = List('x, 'y, 'z) g: List[Symbol] = List('x, 'y, 'z)

However, as we’ve seen before, if we make a little typo, this could turn out to be precisely not what we wanted:

scala> var h = List('x, 'y', 'z) h: List[Any] = List('x, y, 'z)

You see, Any is a pretty good parent type to assign to a List containing both Symbol and Char elements, since Any is at the root of the Scala class hierarchy. Scala inferred that for us, because we gave it (perhaps errantly) two different kinds of objects without telling it specifically what kind of objects we wanted in our collection. So, it looked far and wide through the class hierarchy for a class that could be both Char and Symbol and ended up with Any. While it is true that we could be using objects of type Char as instances of Any, if we expected to have Chars and attempted to do something that Chars can do and Anys cannot, we would then get an error.

scala> h.head < h(1) <console>:9: error: value < is not a member of Any h.head < h(1) ^

This is one of the reasons that many Scala developers who work deeply within its type system lament how it works. It seems really cool and handy at first, but if you rely on type inference, it’s easy to get yourself into a sticky situation.

In the second half of this chunk, we'll take a look at how to declare the types of your objects, and see what type parameters look like for generic types.

That’s actually a lie, Scala will allow all kinds of nonsense if you ask it very nicely by writing a lot of code.  ↩

[fuckyeascala-blog]

Getting Started with Scala pt 7 - Ranges, Tuples, and Comprehensions

Last time around we went over the powerhouse of the collections library, the List. Today, we're going to take a look at a couple more collections that pop up fairly frequently, or that are at least representative of the types of collections that come up often. We have the Range, which is a generated collection that we can use all our awesome collection-y tools on (map, filter, folds, etc), as well as the Tuple, which lets us store data of differing types in the same data structure of a fixed length. Let's take a gander!

No, it’s not a stove

Man, you know – typing out all those lists was really tedious! My fingers hurt and the paint on my L key is starting to wear off. Wouldn’t it be nice if there were a way I could tell Scala that I just wanted all the numbers from 1 until 10 and just have it type those out for me?

scala> 1 until 10 res0: scala.collection.immutable.Range = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)

Crikey I suppose there is. Those guys who wrote Scala are on top of things. It looks like there’s a type called a Range that looks a lot like a list. Thinking about this for a moment, I bet it’s because like our lists of numbers or characters, there’s an ordering of these that makes sense. I’d venture that we can probably use some of the same functions we used on our ordered lists on these Range thingies as well:

scala> (1 to 10).max res2: Int = 10 scala> ('a' until 'm').min res3: Char = a scala> (5 to 20 by 5).sum res4: Int = 50

Wow, that’s nuts! It looks like to is a handy function that’s like until, except that it makes the Range inclusive – just like saying 1 to 5 inclusive[1] – and that by will let us define a step amount, like every other with by 2 or every fifth with by 5.

Now you’re gaining some comprehension

Literally. Scala’s for comprehension is a neat piece of syntactic sugar that does the magic that we expect to be done of Monads. However, we don’t know those yet, so for now, we’ll concern ourselves with the simpler end of what for gives us in regards to Lists and List-like things. Maybe we want 5 even numbers. We already have a few ways of doing that:

scala> 2 to 10 by 2 res0: scala.collection.immutable.Range = Range(2, 4, 6, 8, 10) scala> (2 to 5000 by 2).take(5) res1: scala.collection.immutable.Range = Range(2, 4, 6, 8, 10)

A for comprehension would let us write this slightly differently, as “double of the first 5 numbers”:

scala> for (x <- 1 to 5) yield x * 2 res2: scala.collection.immutable.IndexedSeq[Int] = Vector(2, 4, 6, 8, 10)

I really like the look of this statement and how it reads: “For each of the things from 1 to 5, let’s call that thing ‘x’, and I would like this statement to yield the results of those ’x’s multiplied by 2”. Of course because Scala’s way of handling list-y things is infinitely wonky, we get neither a Range nor a List back, but a Vector which meets the requirement that we yield an IndexedSeq, but that’s unimportant, trust me those are most List-like things for our purposes.

So in a for comprehension, the thing inside the parenthesis is a called an enumerator and involves a generator pointing at a binding. Then, the yield is evaluated for each binding that is generated. So, the 1 to 5 generator generates us a 1 which is bound to x, and then the yield evaluates x * 2, where x is bound to 1, and gets a 2, this becomes the first element in our IndexedSeq, and the generator moves on to the next element and so on. If you’re already familiar with it, this functionality is called mapping, and we’ll be using map all over the place in no time.

However, for does not stop there, oh no! Maybe you want the double of numbers, but you only want the double of numbers that aren’t between –5 and 5. for is like: “yo buddy it’s cool, I got that!”:

scala> for (x <- -10 to 10 if (x > 5 || x < -5)) yield x * 2 res3: scala.collection.immutable.IndexedSeq[Int] = Vector(-20, -18, -16, -14, -12, 12, 14, 16, 18, 20)

Yup, we can add filtering conditions to our generator to make sure we only yield for elements we need!

It can get really crazy, because we can actually have multiple generators, and a yield block will be attempted for every combination of bindings:

scala> for (x <- 1 to 3; y <- 5 to 15 by 5) yield y + x res12: scala.collection.immutable.IndexedSeq[Int] = Vector(6, 11, 16, 7, 12, 17, 8, 13, 18)

As you can see, first we get 1 + 6, 1 + 10, 1 + 15, then 2 + 5, 2 + 10, and so on. Naturally, we can still combine this with filtering to say, select only the even ones:

scala> for (x <- 1 to 3; y <- 5 to 15 by 5; if ((x + y) % 2 == 0 ) ) yield y + x res14: scala.collection.immutable.IndexedSeq[Int] = Vector(6, 16, 12, 8, 18)

No scruples with Tuples!

So we know how to store homogenous collections of things and get to them (with functions, even!), but we’re missing out on the flip side of that still - at some point we’ll probably want to have some kind of collected-together information that is of differing types without Scala inferring some inane common type for them like AnyVal or Any or None. This is where tuples come in. We already know that Lists and other collections have a (relatively) infinite number of objects of the same type. Tuples have a fixed number of objects of potentially differing (heterogenous) types. Making a tuple is super easy, you just put parenthesis around whatever you want to tuplify[2]:

scala> (1, "two") res0: (Int, String) = (1,two)

As a reminder, what happens when we do that with a List?:

scala> List(1, "two") res1: List[Any] = List(1, two)

Boo and hiss, hiss and boo! We certainly can’t do much with an Any. How nice that the tuple assures us in it’s type signature of (Int, String) that it contains exactly one Int and one String. Thanks tuple!

Tuples can contain more than two things if we need to, and pedantic math-y people will then tell you that they are called “triples” and “quadruples” or even worse, “n-tuples” (like 7-tuple), but we’re just going to go ahead and call them all tuples because we’re rebels like that:

scala> ('a', 4, "woohoo!", 'b) res2: (Char, Int, String, Symbol) = (a,4,woohoo!,'b) scala> (List('a', 'b', 'c'), "easy as", List(1, 2, 3), "simple as", List("do", "re", "mi"), 'abc, 123) res3: (List[Char], String, List[Int], String, List[String], Symbol, Int) = (List(a, b, c),easy as,List(1, 2, 3),simple as,List(do, re, mi),'abc,123)

See, even Michael likes his heterogenous collection types.

When it’s time to get the information out of tuple, we use the accessors for its elements, which are just vals preceded by an underscore:

scala> res0._1 res4: Int = 1 scala> res0._2 res5: String = two

Unlike collection indices, these start their numbering at 1, because that’s just how they decided to do it. You can store up to 22 elements in a tuple (via the Tuple22) type. That’s a lot of things! You might be asking – “Why would they only go up to 22?” Well, remember that each tuple is in fact its own type, and so after defining the first 21 tuple types, I assume that someone got to typing out this type signature and then said “OK screw it that’s enough already.”:

case class Tuple22[+T1, +T2, +T3, +T4, +T5, +T6, +T7, +T8, +T9, +T10, +T11, +T12, +T13, +T14, +T15, +T16, +T17, +T18, +T19, +T20, +T21, +T22](_1: T1, _2: T2, _3: T3, _4: T4, _5: T5, _6: T6, _7: T7, _8: T8, _9: T9, _10: T10, _11: T11, _12: T12, _13: T13, _14: T14, _15: T15, _16: T16, _17: T17, _18: T18, _19: T19, _20: T20, _21: T21, _22: T22) extends Product22[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21, T22] with Product with Serializable

As far as I know, there’s no real technical reason to stop at 22-tuples, but if you need more than that you can first define it yourself, and then go seek help, because you need it.

It turns out there are two pretty common uses for tuples. For one, you get them from zip-ing collections together. Calling zip on a collection (list a List) that supports it with another collection will take the first element of each of those, and make it a tuple, then take the second element of each of those collections and then make those a tuple and so on, until one of them runs out of elements!

scala> List(1,2,3,4,5,6).zip(List("a", "b", "c", "d")) res6: List[(Int, String)] = List((1,a), (2,b), (3,c), (4,d))

As you can see, any leftovers in either collection are ignored. Aside from combining collections, it turns out that tuples serve another handy purpose where one might want an ordered set of different types and fixed lengths: function parameters are essentially tuples. In fact, function objects have a tupled method which swaps their parameter lists for a single tuple of the same type:

scala> val f = (a:String, b:Int, c:Symbol) => a + b.toString f: (String, Int, Symbol) => String = <function3> scala> f.tupled res7: ((String, Int, Symbol)) => String = <function1> scala> f.tupled ("bob", 6, 'what) res8: String = bob6

A Practical example

What can we do with some of what we’ve learned so far? How about finding right triangles: we’ll need for comprehensions to find lists of tuples representing the lengths of the sides. Perfect! Specifically, let’s find an algorithm for finding triangles whose sides all add up to a certain number.

First, we’ll probably need to know what our choices are here. I suppose all of the triangles up to a maximum side length of a could simply be defined like so:

scala> def allTriangles(a:Int) = for(x <- 1 to a; y <- 1 to a; z <- 1 to a) yield (x, y, z) allTriangles: (a: Int)scala.collection.immutable.IndexedSeq[(Int, Int, Int)]

On second thought, that’s kind of dumb though. If we’re assembling right triangles, we really only need the triangles where the sum of the first two sides’ squares is equal to the third’s square. We should probably switch that up to include a filter:

scala> def rightTriangles(a:Int) = for(x <- 1 to a; y <- 1 to a; z <- 1 to a; if (Math.pow(x,2) + Math.pow(y,2) == Math.pow(z,2))) yield (x, y, z) rightTriangles: (a: Int)scala.collection.immutable.IndexedSeq[(Int, Int, Int)]

That looks better. To try this out, let’s get all the right triangles whose sides are all 5 or less, which should be just the 3–4–5 right triangle. Let’s give it a shot:

scala> rightTriangles(5) res0: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((3,4,5), (4,3,5))

Hmm. Kind of. We did get the correct triangle, but we actually got it twice in two different forms. Looks like we should change up our generators.

scala> def rightTriangles(a:Int) = for(z <- 1 to a; y <- 1 to z; x <- 1 to y; if (Math.pow(x,2) + Math.pow(y,2) == Math.pow(z,2))) yield (x, y, z) rightTriangles: (a: Int)scala.collection.immutable.IndexedSeq[(Int, Int, Int)] scala> rightTriangles(5) res1: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((3,4,5))

Niiiiice. Now we’re not checking a bunch of extra triangles that we don’t need to. Now, we just need to find triangles that have a sum of sides equal to something in particular. We could probably do this with another for filter.

scala> def rightTriangles(a:Int, b:Int) = for(z <- 1 to a; y <- 1 to z; x <- 1 to y; if (Math.pow(x,2) + Math.pow(y,2) == Math.pow(z,2)); if (x + y + z) == b) yield (x, y, z) rightTriangles: (a: Int, b: Int)scala.collection.immutable.IndexedSeq[(Int, Int, Int)]

Cool! Let’s see if it works! We know the 3–4–5 triangle’s sides add up to 12, so we can check against that:

scala> rightTriangles(5, 12) res2: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((3,4,5)) scala> rightTriangles(5, 10) res3: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector()

Nailed it! Let’s see how he does on some other triangles:

scala> rightTriangles(50, 24) res4: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((6,8,10)) scala> rightTriangles(50, 30) res5: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((5,12,13)) scala> rightTriangles(50, 44) res6: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector() scala> rightTriangles(50, 40) res7: scala.collection.immutable.IndexedSeq[(Int, Int, Int)] = Vector((8,15,17))

Awesome. This has got me missing Trigonometry class. Well hey, we have the lengths of the sides of some right triangles, which means we can probably get the measures of the inside angles – and see how handy having these packaged as tuples is at the same time!

rightTriangles(5, 12) map { t => (180 * Math.acos(t._2/5.0) / Math.PI, 180 * Math.acos(t._1/5.0) / Math.PI) } res8: scala.collection.immutable.IndexedSeq[(Double, Double)] = Vector((36.86989764584401,53.13010235415598))

So, did all of this just blow your mind?! Good. Stick around, we’re just getting started…

Which works, by the way.  ↩

This is not a technical term. I made it up but it sounds awesome.  ↩

[fuckyeascala-blog]

Getting Started with Scala pt 6 - Lists

Are you ready for all of this? We've got a beefy post today, and it's all about Lists. Scala comes with a crazy-powerful set of collections. However, for now we’re going to focus on just one collection that will help us get used to the rest of the language, and also so I don’t go into a huge rant about all the messed up and incorrect bullshit going on in the Collections API.

Lists are (as you probably expected) how we store lists of things. The List is typed to its contents, so you can have a List[Int] containing the numbers 1 through 10 or a List[String] containing the names “Galactus” through “Thanatos”.

Type Parameters

Even though I didn’t want to get too deep into the Collections API quite yet, notice the [] at the end of our types. This is the syntax for a parameterized type – that is, a type whose definition depends on another type. If you’re familiar with Java’s Generics or C++ templates, you’re most of the way there already. We saw this syntax briefly when discussing functions, but only now is it really important for you to start using it. For our purposes right now, a List isn’t much on its own, we need to know that a List is actually a List of Ints with the syntax List[Int].

Lists don’t really look like anything scary or crazy:

scala> List(1,2,3) res0: List[Int] = List(1, 2, 3) scala> List("Galactus", "Mephisto", "Doom", "The Stranger") res1: List[String] = List(Galactus, Mephisto, Doom, The Stranger) scala> List() res2: List[Nothing] = List() scala> List(1, "derp") res3: List[Any] = List(1, derp)

Notice once again what’s happened with type inference in the last examples here. Because we haven’t specified a type that works for List(), it assumes we want a List of Nothing objects (which probably was not what we intended), and while we cannot combine items of totally different types in lists together, if we try to do so, Scala will gladly find a type that both of those types derive from and make it a list of that type – in this case Any, Scala’s way of saying “meh, whatever”. If you want to sound like a fancy-pants, you can blame this on covariance[1].

Lists are at their most useful of course when you can add things to them. There is an operator for this that will seem rather simple, and his name is ++:

scala> List(1, 2, 3) ++ List(4, 5) res4: List[Int] = List(1, 2, 3, 4, 5)

However, Lists work like our good old friend from Computer Science class, the linked list. When we put two lists together like this, the ++ operator has to walk through the whole first list to get to where it should add the second list. This means that ++ can be a pretty sluggish fellow! So how can we construct lists programmatically in a way that isn’t slow? Well, meet the “cons” operator, ::.

scala> 1 :: List(2) res5: List[Int] = List(1, 2)

The cons operator prepends an element to the front of a list. This is super quick since the number of elements Scala must traverse to get to where it needs to add your element is 0. Notice though, that the left operand in cons is always a single element, whereas both operands in ++ are lists.

You don’t suppose we could make a list out of just two elements with cons, can we?

scala> 1 :: 2 <console>:8: error: value :: is not a member of Int 1 :: 2

“Certainly not!”, says Scala. There’s no such thing as a :: defined for Ints on their own. So, we need something related to List that has :: defined and takes other elements. Our friend Nil comes to the rescue.

scala> Nil res7: scala.collection.immutable.Nil.type = List()

Well look at that, Nil is actually an empty list, which means it will definitely have :: defined. Even more revealing is the if we stick that result back in to Scala’s interpreter:

scala> List() res8: List[Nothing] = List()

Looking at the Scala source code[2] we can confirm that this is exactly what Nil is – an object that is a subtype of List[Nothing]:

case object Nil extends List[Nothing] { //…

Don’t worry if that doesn’t make too much sense, since we haven’t discussed how to define types yet, but this actually gives us handy insight into how lists really work! You see, I haven’t been completely honest with you here – a List is actually some series of elements “cons’d” together, with a Nil as the last element.

scala> 1 :: 2 :: 3 :: 4 :: Nil res10: List[Int] = List(1, 2, 3, 4) scala> 1 :: 2 :: 3 :: List(4) res11: List[Int] = List(1, 2, 3, 4) scala> 1 :: 2 :: List(3, 4) res12: List[Int] = List(1, 2, 3, 4) scala> 1 :: List(2, 3, 4) res13: List[Int] = List(1, 2, 3, 4)

This magical Nil is how Scala’s list knows that it’s the end of the list and if we’re iterating, that it’s time to stop what we’re doing because the remaining list is empty. This comes in super handy in recursion.

What does the list do?

A list’s job is to hold things. Really, that should be any collection’s job. We know it does that already, but it wouldn’t be very useful if it just locked them away in its Integer safe never to be opened again. A collection is only as useful as the elements we can access in it, so let’s see what these bad boys are capable of.

For one, we can get things back out of our lists by index (zero-indexed, for what are we, savages?) by calling the apply method on that list. In truth, we usually use the shortcut for this, (), making it looks like a funciton call.

scala> List(1,2,3) res0: List[Int] = List(1, 2, 3) scala> res0(1) res1: Int = 2 scala> res0.apply(1) res2: Int = 2

Be careful though, because as you might expect, accessing an index beyond the number of elements in your list will schedule you a reunion with a familiar friend from Java.

scala> res0.apply(3) java.lang.IndexOutOfBoundsException: 3 // …

Aside from using indices to get to list elements, there are some canonical list operations defined for getting to important elements in linear collections. The head function returns the “head” of a list, while tail returns everything but the head:

scala> res0.head res3: Int = 1 scala> res0.tail res4: List[Int] = List(2, 3)

Conversely, we’ve got last and init, which will give us the last element and everything up to the last element respectively:

scala> res0.last res5: Int = 3 scala> res0.init res6: List[Int] = List(1, 2)

As you might expect, these will still give us a nasty error if used inappropriately:

scala> List().head java.util.NoSuchElementException: head of empty list // … scala> List().tail java.lang.UnsupportedOperationException: tail of empty list // …

Therefore, it might be interesting to know some things about your list like how long it is, and for that, length and size are synonymous (size simply calls length):

scala> res0.length res9: Int = 3 scala> res0.size res10: Int = 3

Usually though, when iterating over lists, we might not care how long the thing is, just whether there is more to iterate over, so most of the time, what we actually want to know is if the list isEmpty:

scala> res0.isEmpty res11: Boolean = false scala> List().isEmpty res12: Boolean = true

So, we might want to do something like this:

scala> if (res0.length >= 1) res0.head res13: AnyVal = 1

But what we probably want is really:

scala> if (!res0.isEmpty) res0.head res14: AnyVal = 1

Or even (and here I go sneaking things in!):

scala> if (res0.nonEmpty) res0.head res15: AnyVal = 1

So what if we want more than one element from our list? Scala’s got us covered with take as well:

scala> res0.take(1) res16: List[Int] = List(1) scala> res0.take(3) res17: List[Int] = List(1, 2, 3) scala> res0.take(2) res18: List[Int] = List(1, 2) scala> res0.take(4) res19: List[Int] = List(1, 2, 3) scala> List().take(1) res20: List[Nothing] = List()

Notice a little bit of a difference – because we potentially want more than one element back, we know we’re going to be getting a new List back, and that if we ask for more elements back than the list has, we’re going to be getting all that the List has to offer, but not explode in a fiery ball of exceptions. Hurray to not exploding!

The flip side of take is drop, which is the opposite of take in the same way that head is the opposite of tail – you get everything after the elements that you dropped.

scala> List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10).drop(2) res21: List[Int] = List(3, 4, 5, 6, 7, 8, 9, 10) scala> List(1, 2, 3, 4, 5, 6, 7, 8, 9, 10).drop(8) res22: List[Int] = List(9, 10) scala> List().drop(9001) res23: List[Nothing] = List()

Are you getting all this? Probably. You’re good at this kind of thing.

There’s a few other handy List functions around that it won’t hurt us to know about. There are plenty more than these, but this is just to give you an idea of the kinds of things that are already defined for you. You can reverse lists:

scala> List(1,2,3).reverse res24: List[Int] = List(3, 2, 1)

For things that make sense to be ordered (numbers, characters, strings, other objects that you define on your own), you can use some handy functions for comparing the elements inside collections:

scala> List(1,2,3).max res25: Int = 3 scala> List(1,2,3).min res26: Int = 1 scala> List("jane", "kid koala", "bob").min res27: String = bob scala> List("jane", "kid koala", "bob").max res28: String = kid koala scala> List("jane", "kid koala", "bob").sorted res29: List[String] = List(bob, jane, kid koala)

Similarly, for things that make sense to be added together, there are equally handy functions for summing or finding products of lists:

scala> List(1, 4, 6, 2, 6, 7.0).sum res30: Double = 26.0 scala> List(1, 4, 6, 2, 6, 7.0).product res31: Double = 2016.0

This won’t work as easily for other types of things for which it is not as obvious how they should be added together or multiplyed, like Strings:

scala> List("janet", "brad", "frank", "magenta").sum <console>:8: error: could not find implicit value for parameter num: Numeric[String] List("janet", "brad", "frank", "magenta").sum ^ scala> List("janet", "brad", "frank", "magenta").product <console>:8: error: could not find implicit value for parameter num: Numeric[String] List("janet", "brad", "frank", "magenta").product

Why hello, what is this we have? Scala could not find implicit value, which tells us that part of the secret behind all of these handy predefined collection functions is a super fancy-pants feature of Scala called “implicit conversion[3]”. Instead of talking too much about that now, we’re instead going to take this as our cue that perhaps this is a good place to stop and move on, and revisit this topic when we have some even fancier pants ourselves.

Haven't had enough of the collections yet? HAVE NO FEAR YOU PROGRAMMING BEAST OF A PROGRAMMER – there's more to come. Next time we're going to talk about a some more collection-y things, like ranges and tuples, which will teach us about how lazy types (that don't actually generate their values until you need them) and more finitely-sized things that are heterogenous work.

If you're giggling inside because I wrote "hetero", you're in the right place.

Covariant types are types where given a pair of other types, B and A, if B is a subtype of A, then the Covariant type of B is a subtype of the Covariant type of A. Therefore, given String and Int are subtypes of Any, List[String] is a subtype of List[Any], as is List[Int].  ↩

At the time of this writing, the code was located at https://github.com/scala/scala/blob/master/src/library/scala/collection/immutable/List.scala  ↩

Implicit conversion is an automatic conversion of one type into another based on some predefined rules.  ↩

[fuckyeascala-blog]

Getting Started with Scala, pt 5 - On One Condition

Well folks, it's about time I start talking about how you might use this wacky language for something interesting. For that, you're going to need to know how to do conditional statements. Let's get on that.

By this point you know more than you’d ever want to know in an introduction (that took several weeks) about declaring immutable values and first-class functions. You’re also probably pretty cheesed that you don’t even know how to do a conditional. I had high hopes that you’d get really excited about that stuff, but you probably want me to get on with it so you can write some programs.

Well, Scala’s basic conditional is the if statement, which is pretty unremarkable if you know other imperative languages. It can (but doesn’t have to) be accompanied by an else to give an alternate branch to your logic. Be advised though, if you want to take full advantage of type inference, you should always give an else to your conditionals. Actually, because you don’t like mutable state and side effects I’m sure you always give a good else branch to your conditionals, you’re just that awesome! Take a look at what happens to our types here"

scala> if (1 > 0) 5 res0: AnyVal = 5 scala> if (1 > 0) 5 else 10 res1: Int = 5

See what’s going on there? In our second example, if we provide an else, we get back an Int as expected, but if we don’t have an else branch, Scala still gives us a 5 back, but its type is of AnyVal (meaning, well, its value could be interpreted as just about anything)! Why is that?

Well, as we already know, Scala supports both imperative and functional programming styles, and will do its best to figure out types for you based on how your logic flows. In imperative programming, an if statement introduces a branch that may never be executed, but if it is, who knows what will happen? Certainly not the compiler. It could be converting our value to a String, or causing a side effect like printing the value out the standard output, or saving it to the database (which would give us a Unit back) – anything! In fact, this is why our return value is represented as AnyVal. However, if we provide an else branch like good responsible people always do, the compiler will always be able to infer the precise type that could result from either branch of our conditional. In this case, it can tell that our statement will always return some kind of Int, so it gladly gives us that type back. In more purely functional languages, else is required due to precisely this potential for impure branches of logic that could have a return value under some conditions, but may have no value at all under other conditions!

Let’s look at another practical example of defining a function that uses a conditional. A Collatz sequence is a series of numbers that is generated by a simple dividing and adding algorithm, and a gentleman whose name you can probably guess conjectured that eventually, no matter what number you start at, if you follow the sequence generated by this algorithm, you’ll eventually get a 1 back. Here’s how we might get the next number in the sequence:

def nextCollatz(i:Int) = { if (i % 2 == 0) i / 2 else 3 * i + 1 }

The first thing you’ll probably note is something we haven’t seen yet, which is the use of those ugly braces that Java loves so much. They allow us to write multi-line statements which evaluate to a single expression – much like blocks in some other languages. We could have included multiple stateful statements in function body, but here we’re simply using it so that we don’t have to put if (i % 2 == 0) i / 2 else 3 * i + 1 all on one line.

We can see that type inference is doing its job when we load this back into the scala interpeter, as it correctly infers that we would always like our funciton to return an Int even though we didn’t declare that specifically:

scala> :l funky.scala Loading funky.scala... nextCollatz: (i: Int)Int

According to Herr Collatz, if we start at 13, it should take us 9 steps to get back to 1. That certainly works!

scala> // 13 -> 40 -> 20 -> 10 -> 5 -> 16 -> 8 -> 4 -> 2 -> 1 scala> nextCollatz(13) res0: Int = 40 scala> nextCollatz(40) res1: Int = 20 scala> nextCollatz(20) res2: Int = 10 scala> nextCollatz(10) res3: Int = 5 scala> nextCollatz(5) res4: Int = 16 scala> nextCollatz(16) res5: Int = 8 scala> nextCollatz(8) res6: Int = 4 scala> nextCollatz(4) res7: Int = 2 scala> nextCollatz(2) res8: Int = 1

Obviously you’ll never want to type that in for some larger numbers, so we’ll revisit automating this sequencing when we talk about writing recursive functions.

This was admittedly a bit of a quickie, but it's important to realize that every statement has a return type, and if you don't provide one, Scala is going to pick one that you probably didn't mean. In the context of Scala, if you're writing crappy code, you're going to end up with a crappy type on your objects and function signatures, and that should tell you that you're doing it wrong.

Next time around, we're going to start exploring the other part of having something actually useful to do in a language, which is using collections. Because I'm lazy, we're only going to explore the most base of collections in the next post, the List. Get your next-item pointers ready!

[fuckyeascala-blog]

Getting Started with Scala, pt 4 - what the function?

There's a few ways to make functions, and if you're coming from an object-oriented world, some of them are going to seem a little weird. If you're coming from a Lisp or ML back, they're going to look ugly as sin because of all the syntax. This is just something you'll have to deal with if you want to learn a language that people actually use in production, you erudite.

In the last edition, we saw a short example of the different keywords used to define thing. We saw that when we make variable objects, we can assign them to things with val and def and that other one that's bad. In a post before that I mentioned that functions are actually objects. Why do I bring this up when we were just talking about how functions are objects? Well because we’re going to use val and def to prove it! And what's the best way of figuring something out? Fucking around with it until you break it, naturally!

Let’s write some code!

I am perhaps taking a leap of faith by assuming you like writing code. If I’m wrong in this assumption, I apologize. If you’d like to complain about it, please handwrite your complaint on a 3“ by 5” lined index card and promptly file it away in the nearest rubbish container for safe keeping. Don’t worry, I’ll find it there. I’ll be sure to respond to all such grievances in due course. The rest of you, because you like writing code so much, you probably have been itching to do so for about 1400 words, so let’s get started with that.

We’ll go over the syntax of functions by playing with them in the Scala REPL. First though, we’ll need a function to use. Open up your favorite text editor (but don’t tell the other readers what your favorite is, lest we start a religious war of sorts) and create a file called funky.scala containing the following code[1]:

def addOne(x:Int):Int = x + 1

This is perhaps the most common way to define a function in Scala. It reads something like “Define a function ‘addOne’ that takes an ‘Int’ parameter ‘x’ and returns and ‘Int’, which is equal to x + 1”.

Now, open a terminal and change to the directory where you saved that file and fire up your Scala REPL by typing scala. Once you’ve got the scala> prompt, type :load funky.scala[2]

scala> :load funky.scala Loading funky.scala... addOne: (x: Int)Int

Scala is telling us that it has loaded one definition into our current scope with the line: addOne: (x: Int)Int. We can now use that function in the REPL.

scala> addOne(3) res0: Int = 4

Wow, computers! Am I right?! Now what were we talking about before? Ahh, yes – the relation between def and val.

It turns out, that’s not the only way to create that function. We could also create an anonymous function value that takes an integer and returns another integer like so:

scala> val addAnotherOne = (x:Int) => x + 1 addAnotherOne: Int => Int = <function1> scala> addAnotherOne(4) res1: Int = 5

The definition reads something like “Create a value (an object) ‘addAnotherOne’ which is equal to a function that takes an ‘Int’ parameter ‘x’ and returns x + 1”. As you can see, it works the same as our previous function definition for all the intents and purposes that we care about right now. We can even see that the Scala REPL is telling us this is an object that is an arity–1 function where it says <funciton1>.

But wait, there’s more! We could even define a arity–0 function that returns a function that takes an integer and returns an integer like this guy right here:

scala> def addWeirdOne = (x:Int) => x + 1 addWeirdOne: Int => Int scala> addWeirdOne(5) res2: Int = 6

This one is a method ‘addWeirdOne’ that takes 0 parameters and which returns a function that takes 1 parameter (called ‘x’), which immediately gets any arguments passed to the method and applies them. That’s a bit wacky, perhaps. Things are getting a little crazy!

Even wackier, although perhaps pleasing to the Haskell fans in the audience, we could give it a full type signature so that our anonymous function doesn’t need to define the type it takes in its own signature:

scala> val addHardToTypeOne:(Int => Int) = x => x + 1 addHardToTypeOne: Int => Int = <function1>

And like the addWeirdOne we could make an arity–0 function that returns that instance, because why not?

scala> def hardToTypeMethod:(Int => Int) = addHardToTypeOne hardToTypeMethod: Int => Int

As you can see, these all work in much the same way in practice.

scala> addHardToTypeOne(6) res3: Int = 7 scala> hardToTypeMethod(7) res4: Int = 8

Hopefully, this little play session has adequately demonstrated that functions in Scala are in fact objects, and that they are about as “first-class citizen” as it gets. Alternatively, this might have just scared the crapola out of you. If that’s the case, have no fear! In all practicality, you won’t have to worry too much about the differences of what we’ve done here – as you can see, they have all worked exactly the same way when it comes to actually adding 1 to a number. The good news is, syntax-wise, we’ve covered nearly everything you’ll need to know about defining functions and values, all under the secret pretense of proving some crap about functions you probably don’t even care about right now! Stick that in your craw – we’ll be dealing with declaring anonymous functions and passing them around as values all throughout this series, and with practice, it will come naturally.

Let’s write some actually useful code!

So you’ve learned how to define some functions (or you skipped that last section because you think I’m a crazy person introducing that in the first chapter) and how to load them into your REPL. Hopefully you haven’t closed your editor in a fit of rage because we’ll need that file again here.

Previously we were just adding one to a number, but what if we wanted to double our number instead? Let’s a function called twiceTheFun

def twiceTheFun(x:Int):Int = x + x

We can load our file again the same way we did before with :l funky.scala (:l is a shortcut for :load)

scala> :l funky.scala Loading funky.scala... addOne: (x: Int)Int twiceTheFun: (x: Int)Int

And totally boring and unsurprising we can use it like we did before.

scala> twiceTheFun(8) res0: Int = 16 scala> twiceTheFun(9) res1: Int = 18

Because you’re a smart and experienced software-making person, I know that right now your soul is screaming out: “I know this is just an example, but you have shard functionality there and you can refactor it why aren’t you doing that it is driving me crazy please for the love of all that is good just…” at which point I will cut you off and say “Yes, you are right let’s do that.” We can define our functions in a way that they call other common functions!

Add another function to funky.scala called sumOf:

def sumOf(x:Int, y:Int):Int = x + y

And that means we could refactor our other functions to look like this!

def addOne(x:Int):Int = sumOf(x,1) def twiceTheFun(x:Int):Int = sumOf(x,x)

But do they work the same, you say?! Of course they work the same, silly, why would I make them a trivial example in the first chapter if they didn’t?

scala> :l funky.scala Loading funky.scala... addOne: (x: Int)Int twiceTheFun: (x: Int)Int sumOf: (x: Int, y: Int)Int scala> addOne(5) res2: Int = 6 scala> twiceTheFun(8) res3: Int = 16 scala> sumOf(5, 8) res4: Int = 13

If we were feeling really crazy, we could take that a step further and define a more complex function too, why not?

scala> def someDoublyFun(x:Int,y:Int) = sumOf(twiceTheFun(x), twiceTheFun(y)) someDoublyFun: (x: Int, y: Int)Int scala> someDoublyFun(5,8) res5: Int = 26

Although trivially simple, this demonstrates a very common (and smart!) pattern in Scala. We take functions that are clearly accurate and combine them to make more complex functions. This makes our code clean and concise, so we’re not repeating ourself, so we’re not repeating ourselves. In the future, you may discover that doubling something is in fact a function of multiplying it by two instead of adding a number to itself. Because you’ve split up your functions into very simple ones, you’ll only have to change your twiceTheFun function for your program to remain correct. Very crafty of you!

Ok, hopefully you've got some good learning under your belt there. Now, go forth and practice and break them a few times and ponder the reasons that Scala doesn't work like whatever language you're coming from, and get really mad at that, so as to prepare yourself for further enlightenment as you go on reading the posts to come. Next time around we're going to do a quicky about if and else. If that's sounds dumb to you, I can pretend it's going to have clickbait headline like:

Scala screwed up the types of your statements because you don't know how to use it with this one neat trick…

See you on the next one.

If you don’t know how to create a Scala file in your text editor, this may not be the blog for you. That's cool, it's no big deal, just go do some searches on Bing and come back when you know what's up.  ↩

Much like :type, :load is function of the Scala REPL, and not actually part of the scala language. It loads files containing Scala code into the REPL so that you can run the code that they contain.  ↩

[fuckyeascala-blog]

Getting Started with Scala, pt 3 - def, val and var

In Scala, there are three keywords used to assign, define and declare objects: def, val and var.

val is used to declare values. These are declarations that can’t be reassigned later. That’s good because if values stay the same in any scope, it makes our program easier to understand for both us and for the Scala compiler.

var on the other hand is used to declare variables. These declarations can be reassigned later, but mutable state is bad so you should avoid using var at all costs because eventually it will make you grow hair on your palms and everyone will know what you’ve been up to. Of course you’ll need to use var sometimes (otherwise it wouldn’t be there), but hopefully you’ll remember this warning and avoid it at all costs next time you think about it.

Lastly, there’s def, which we use to declare methods, but you can technically just say like def x = 1 and that's legal. Just like val these are immutable as well, but be careful because they will get reevaluated with whatever they've closed around, even if that value has changed! It's probably just safer to us val when you mean val.

Here’s a little bit of how to use these. I’m sure you’ll get it, you’re a clever person and you catch on quickly!

scala> val a = 5 a: Int = 5 scala> var b = 6 b: Int = 6 scala> def c = 7 c: Int scala> :type a Int scala> :type b Int scala> :type c Int scala> a + b res0: Int = 11 scala> a + c res1: Int = 12 scala> def d = a + b d: Int scala> d res2: Int = 11 scala> b = 1278312 b: Int = 1278312 scala> d res3: Int = 1278317

(Note: the :type command is not a Scala language function, but a command in the Scala REPL. You can use it in the interactive REPL, but it won’t work in your Scala code)

Do yourself a favor and assign a new value to a and see what happens. Hint: it blows up and won't let you do it.

This was another short one, but understanding the importance between these very basic keywords is pretty important. Next time around we're going to use these to define some simple functions, and go over a bunch of different syntax for defining functions using these keywords and talk a little bit about the implications of defining them each way. Be prepared because it's going to get weird: Scala has some powerful options for how you define or declare functions and methods, and while several different ways might be valid, only one might actually be what you want. Anyways, more on that in the next one…

[fuckyeascala-blog]

Getting Started with Scala, pt 2 - How do functions work?

Chances are if you found this blog, you’re interested in Scala in part because you heard it was a functional language, meaning it primarily uses functions as its method of getting things done. Well, Scala is also an object oriented language, and functions in Scala are also objects, making them as first-class as anything else you use in Scala. Pretty sweet, huh? In fact, we were actually using functions through the whole last post too, and unbeknownst to you, they’ve actually been functions that are also objects!

In the case of some expression such as 1 == 2, we are actually calling a method on the 1 object, which is 1.==. When we call it, Scala is actually using an object that extends the Function2 trait, so the resulting object is of type Function2[Int,Int,Boolean]. That function object then has its apply method called, to provide us our result. When we call 1.==, it is actually using a partially-applied function which is the same as the ==’ method defined on Int, but with the first parameter assigned as the 1 object.

If that made sense, awesome. If it didn’t, don’t worry, because it won’t hinder your enjoyment or productivity, and it will make sense in time.

Assuming you believe me that “operators” are really just functions, let’s take a look at some examples of how Scala handles this syntax:

scala> 5.==(6) res0: Boolean = false scala> 5.== 6 res1: Boolean = false scala> 5 == 6 res2: Boolean = false

For those of you familiar with other C-style languages, this breakdown of how Scala provides syntactic sugar to make its object methods feel like simple operators should seem natural. In the case of ==, we have a function that takes one argument (since the first argument of our equality is the 5), and Scala allows us to drop the parenthesis for situations where the parameters to a function can be easily inferred (such as arity–1 functions[1]) – giving us 5.== 6. Scala also allows us to disregard the . on the calling object for arity–1 methods – making our expression 5 == 6. This is called infix notation.

This is not the case however, with functions that require multiple parameters. Scala requires us to use parenthesis for any more than 1 argument to a method call:

scala> math.pow(2, 4) res0: Double = 16.0 scala> math.pow 3, 4 <console>:1: error: ';' expected but integer literal found. math.pow 3,4

I know there wasn't a whole lot of code this time around, and you might still be confused as to what "traits" are or what it really means for a function to also be an object, but don't worry we'll get there. So far all I've presented is how to like, add shit to together, which is kind of lame. However, I need you to nail down some basic concepts before I can start showing you the really wacky stuff, so bear with me.

Later this week, I'll give you a quick overview that's mostly code examples of the difference between def, val, and var, the keywords that Scala lets you use to define things in the environment. With those, we can start building some maybe almost actually useful programs, instead of letting the Scala REPL basically just be a calculator.

Function arity is number of arguments a function accepts. Fancy math guys say “the arity of a function is the dimension of the domain in the function’s corresponding Cartesian product.” Functions that take one argument are “monadic”, functions that take two are “dyadic”, three are “triadic”, and so on. In practice, this information is of very little use except for sounding like a smarty-pants in front of your peers.  ↩

[fuckyeascala-blog]

Getting Started with Scala, pt 1

Uggggggh, there's so man Scala blogs, amirite? Unfortunately a lot of them are regurgitating some shit from a Stack Overflow post out of context and you just go "Um, wat how… errrr. Yea that." and move on. Some of the others are totally wicked sweet and they talk about all this theoretical math and kind of chide you for not doing the thing they're talking about in Agda or Coq. Those are pretty cool if you can read the damn things. I'm a pretty smart dude every once in a while, and some of those discussions leave my head spinning.

Well, basically my whole goal in life ever since I was born was to force you (sometimes even through violence) to enjoy our ugly yet extremely powerful language. Naturally, I'll also explicitly ban you from doing what I like to call "stupid things". and just for kicks, I probably won't tell you what those are ahead of times, because I'm a horrible human being.

Instead of focusing on some super deep domain-specific topics for graphics or sound or theorem proving and category theory, I'm going to give you Scala how I think you want it: in plain english and for smart folks like your wonderful selves who already know how to program at least a little bit, just not in Scala. If we're both lucky, you'll understand a lot more about how Scala differs from a bunch of other languages, and you might even learn some of that super fancy stuff along the way as I covertly inject it into the series.

Let's get started.

Installing

Let's start light. How do you install Scala? Well, if you paid way too much for your computer and you already develop software a little bit, you can probably do this:

brew install scala

Or, if you are a zealot for freedom and believe that all people should have the right to know what their software does blah blah blah (let's face it, you really just don't like paying for things), you can probably do this next thing, or at least know how to translate it into the appropriate incantation for one of the seventeen operating systems you have installed side by side:

sudo apt-get install scala

If you're on Windows, well, go find your local MVP and Microsoft Developer Evangelist and get them in a conference call for a good 45 minutes. Actually, don't do that, 'cause they'll just convince you to use C# instead. Rather, you Windows people or any other wacky operating system can go to http://www.scala-lang.org/download/ and follow the installation directions there for how to get Scala working on your platform.

Easing in

To get comfy with Scala, let’s open the interactive shell so we can play around. At your terminal, type scala. You should get see something like this:

Welcome to Scala version 2.10.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_51). Type in expressions to have them evaluated. Type :help for more information. scala>

Huzzah! You’ve got yourself some Scala. As it is par for the course of any new programming language tutorial, you can do some simple math:

scala> 5 + 82 res0: Int = 87 scala> 37 * 18 res1: Int = 666 scala> 3293 - 3721 res2: Int = -428 scala> 7 / 3 res3: Int = 2 scala> 7 / 3.0 res4: Double = 2.3333333333333335

When an expression contains more than one operator, Scala executes them in a precendence order that you might be familiar with from grade school.

scala> 10 * 100 - 500 res5: Int = 500

As you also might expect, we can change this precedence order using parenthesis.

scala> 10 * (100 - 500) res6: Int = -4000

Revolutionary! I bet you’re really impressed now. (It’s OK, I know that you are not, but hang in there. We will get to the cool stuff soon.)

Boolean logic also works as you might expect, and uses the algebraic operators && and || that you are also likely familiar with from other languages like C and Java:

scala> true && true res0: Boolean = true scala> false && true res1: Boolean = false scala> true || false res2: Boolean = true scala> !false res3: Boolean = true scala> !(true && true || false) res4: Boolean = false

Likewise, equality operations use the classic == and !=.

scala> 1 == 2 res5: Boolean = false scala> 3 == 3 res6: Boolean = true scala> 7 != 9 res7: Boolean = true scala> 0 != 0 res8: Boolean = false

Although, if you’re coming from a Java or similar background, you might be surprised by something like this:

scala> "Scala" == "Scala" res9: Boolean = true scala> "Scala" == "Crappy" res10: Boolean = false scala> "Scala" != "Crappy" res11: Boolean = true

Scala improves on some of its predecessors by defining common operations (like equality) for common types (like the Strings we used above). Careful though, because this helpful property of type inference can lead to some results you expect, like

scala> "Scala" == 7 res12: Boolean = false

But it can lead to many you might not expect:

scala> "7" == 7 res13: Boolean = false scala> '7' == 7 res14: Boolean = false scala> "Scala" == 'Scala res14: Boolean = false

You see, Scala is strongly typed, so everything in a Scala program has a definite type like Int or String or DoohickeyTransformerMonad, but it includes some automatic reasoning about what objects are of what type, and will attempt to figure out what you mean by some expression. Usually, Scala won’t attempt to do any comparison of the value of differently-typed objects unless you’ve defined a way for it to do so, so seemingly like values of 7 and '7' are considered to be different because the value of the object is being determined based on how your expression would work with the most common underlying type, which may not be what you intended. While this might seem confusing initially, especially if you don’t have a lot of experience with strongly-typed languages, the good news is most of the time it saves you more thinking and typing than you know, and you can accept it as rote that it is a good thing, because I say it is, most of the time.

Next time: a bit about functions…