Daily scala

Scala 2.8 added the break control flow option. It is not implemented as a special language feature. Rather it is simply implemented as an object/trait using standard Scala mechanisms. If you are interested in creating a control flow object similar to this look at the Defining Custom Control Structures post.

The Break functionality is works basically how you would expect:

1. // Import the control flow methodsmethods
2. scala> import util.control.Breaks._
3. import util.control.Breaks._
4. // pass a function to the breakable method
5. scala> breakable {
6.      | for (i <- 1 to 10 ) {
7.      | if(i > 5) break  // call break when done
8.      | println(i)
9.      | }
10.      | }
11. 1
12. 2
13. 3
14. 4
15. 5

Pretty intuitive but beware, break only breaks out to the first enclosing breakable. Here is an example of the issue:

1. scala> def loop(f : Int => Boolean) = breakable {
2.      | for (i <- 1 to 300) if (f(i)) break else println(i)
3.      | }
4. loop: (f: (Int) => Boolean)Unit
5. // This never ends because break is caught by breakable in the loop method
6. scala> breakable {
7.      | while(true) {
8.      | loop{ i => break; true }
9.      | }
10.      | }

Fortunately the implementers provide an elegant way to handle these sorts of cases. The Breaks object extends the Breaks class. By instantiating other instances of Breaks it is possible to control which breaks capture

1. scala> import scala.util.control._
2. import scala.util.control._
3. scala> 
4. scala> def loop(f : Int => Boolean) = {
5.      |   val Inner = new Breaks
6.      |   Inner.breakable {
7.      |     for (i <- 1 to 4) if (f(i)) Inner.break else println(i)
8.      |   }
9.      | }
10. loop: (f: (Int) => Boolean)Unit
11. scala> 
12. scala> val Outer = new Breaks
13. Outer: scala.util.control.Breaks = scala.util.control.Breaks@1ba4806
14. scala> Outer.breakable {
15.      |   while(true) {
16.      |     loop{ i => if(i==4) Outer.break; false}
17.      |   }
18.      | }
19. 1
20. 2
21. 3

Scala 2.8 has some very significant differences from Scala 2.7 so if you want to migrate from Scala 2.7 to 2.8 you might want to view this Stack overflow topic:

What are the biggest differences between Scala 2.8 and Scala 2.7?

It has some good tips.

_ Scala 2.8 only tip _

Unzip is a handy companion to partition.
- Partition divides a traversable into two traversables by a boolean predicate.
- Unzip divides a traversable into two by dividing each element into two parts (each becomes an element in one traversable). If an element is a Tuple2 then each tuple is divided into two otherwise a function is required to divide an element into two.

1. // basic usage
2. scala> List((1,2),(2,3)).unzip
3. res2: (List[Int], List[Int]) = (List(1, 2),List(2, 3))
4. /* 
5. tuples can be of different types 
6. and the resulting traversables reflect the differing types
7. */
8. scala> List((2,"a"),(3,"b")).unzip
9. res3: (List[Int], List[java.lang.String]) = (List(2, 3),List(a, b))
10. // Maps are Traversable[Collection] so unzip works with them
11. scala> Map(1 -> 2, 3 -> 4).unzip
12. res1: (scala.collection.immutable.Iterable[Int], scala.collection.immutable.Iterable[Int]) = (List(1, 3),List(2, 4))
13. // Of course sets result in sets and duplicates are collected to a single element
14. scala> Set((1,2),(2,2)).unzip
15. res7: (scala.collection.immutable.Set[Int], scala.collection.immutable.Set[Int]) = (Set(1, 2),Set(2))
16. /*
17. Arbitrary elements can be unziped if a method is provided to decompose each element
18. */
19. scala> List("one word", "another word").unzip {e => (e takeWhile {_ != ' '}, e dropWhile {_ != ' '})} 
20. res6: (List[String], List[String]) = (List(one, another),List( word,  word))
21. /*
22. The following shows the same function 
23. applied with map.  It results in a single
24.  list of Tuples rather than two lists of single elements
25.  */
26. scala> List("one word", "another word").map {e => (e takeWhile {_ != ' '}, e dropWhile {_ != ' '})}  
27. res8: List[(String, String)] = List((one, word), (another, word))

Thanks to Scala 2.8's default parameters case classes have a couple wonderful new features in Scala 2.8. Specifically the copy method and the ability to have case classes with default parameters.

1. // constructor methods have defaults defined
2. scala> case class Node (name:String, left : Option[Node] = None, right : Option[Node] = None)                          
3. defined class Node
4. // the name is the only required parameter because it does not have a default
5. scala> val child = Node("leaf") 
6. child: Node = Node(leaf,None,None)
7. // left is being assigned here because the name of the parameter is not explicit
8. scala> val parent = Node("parent", Some(res0))
9. parent: Node = Node(parent,Some(Node(leaf,None,None)),None)
10. // now the left node is not defined just the right
11. scala> val node = Node("node", right=Some(res0))
12. node: Node = Node(node,None,Some(Node(leaf,None,None)))
13. /* 
14. The real power is the copy constructor that is automatically generated in the case class.  I can make a copy with any or all attributes modifed by using the copy constructor and declaring which field to modify
15. */
16. scala> parent.copy(right = Some(node))
17. res4: Node = Node(parent,Some(Node(leaf,None,None)),Some(Node(node,None,Some(Node(leaf,None,None)))))
18. scala> parent.copy(left=None)         
19. res5: Node = Node(parent,None,None)
20. scala> parent.copy(name="hoho")
21. res6: Node = Node(hoho,Some(Node(leaf,None,None)),None)
22. scala> parent.copy(name="hoho", left=None)
23. res7: Node = Node(hoho,None,None)

This topic discusses non-strict collections. There is a fair bit of confusion with regards to non-strict collections: what to call them and what are they. First lets clear up some definitions.

Pre Scala 2.8 collections have a projection method. This returns a non-strict collections. So often non-strict collections are called projections in Pre Scala 2.8
Scala 2.8+ the method was changed to view, so in Scala 2.8+ view sometimes refers to non-strict collections (and sometime to a implicit conversion of a class)
Another name for non-strict collections I have seen is "lazy collections."

All those labels are for the same thing "non-strict collections" which is the functional programming term and which I will use for the rest of this topic.

As an excellent addition to this topic please take a look at Strict Ranges? by Daniel Sobral.

One way to think of non-strict collections are pull collections. A programmer can essentially form a sequence of functions and the evaluation is only performed on request.

Note: I am intentionally adding side effects to the processes in order to demonstrate where processing takes place. In practice the collectionsshould be immutable (ideally) and the processing the collections really should be side-effect free. Otherwise almost guaranteed you will find yourself with a bug that is almost impossible to find.

Example of processing a strict collection:

1. scala> var x=0
2. x: Int = 0
3. scala> def inc = {
4.      | x += 1
5.      | x
6.      | }
7. inc: Int
8. scala> var list =  List(inc _, inc _, inc _)
9. list: List[() => Int] = List(<function0>, <function0>, <function0>)
10. scala> list.map (_()).head
11. res0: Int = 1
12. scala> list.map (_()).head
13. res1: Int = 4
14. scala> list.map (_()).head
15. res2: Int = 7

Notice how each time the expression is called x is incremented 3 times. Once for each element in the list. This demonstrates that map is being called for every element of the list even though only head is being calculated. This is strict behaviour.

Example of processing a non-strict collection with Scala 2.7.5
For Scala 2.8 change project => view.

1. scala> var x=0
2. x: Int = 0
3. scala> def inc = {
4.      | x += 1
5.      | x
6.      | }
7. inc: Int
8. scala> var list =  List(inc _, inc _, inc _)
9. list: List[() => Int] = List(<function0>, <function0>, <function0>)
10. scala> list.projection.map (_()).head
11. res0: Int = 1
12. scala> list.projection.map (_()).head
13. res1: Int = 2
14. scala> list.projection.map (_()).head
15. res2: Int = 3
16. scala> list.projection.map (_()).head
17. res3: Int = 4

Here you can see that only one element in the list is being calculated for the head request. That is the idea behind non-strict collections and can be useful when dealing with large collections and very expensive operations. This also demonstrates why side-effects are so crazy dangerous!.

More examples (Scala 2.8):

1. scala> var x=0
2. x: Int = 0
3. scala> def inc = { x +=1; x }
4. inc: Int
5. // strict processing of a range and obtain the 6th element
6. // this will run inc for every element in the range
7. scala> (1 to 10).map( _ + inc).apply(5)
8. res2: Int = 12
9. scala> x
10. res3: Int = 10
11. // reset for comparison
12. scala> x = 0
13. x: Int = 0
14. // now non-strict processing but the same process
15. // you get a different answer because only one
16. // element is calculated
17. scala> (1 to 10).view.map( _ + inc).apply(5)
18. res6: Int = 7
19. // verify that x was incremented only once
20. scala> x
21. res7: Int = 1
22. // reset for comparison
23. scala> x = 0
24. x: Int = 0
25. // force forces strict processing
26. // now we have the same answer as if we did not use view
27. scala> (1 to 10).view.map( _ + inc).force.apply(5)
28. res9: Int = 12
29. scala> x
30. res10: Int = 10
31. // reset for comparison
32. scala> x = 0
33. x: Int = 0
34. // first 5 elements are computed only
35. scala> (1 to 10).view.map( _ + inc).take(5).mkString(",")
36. res9: String = 2,4,6,8,10
37. scala> x
38. res10: Int = 5
39. // reset for comparison
40. scala> x = 0
41. x: Int = 0
42. // only first two elements are computed
43. scala> (1 to 10).view.map( _ + inc).takeWhile( _ < 5).mkString(",")
44. res11: String = 5,7
45. scala> x
46. res12: Int = 5
47. // reset for comparison
48. scala> x = 0
49. x: Int = 0
50. // inc is called 2 for each element but only the last 5 elements are computed so
51. // x only == 10 not 20
52. scala> (1 to 10).view.map( _ + inc).map( i => inc ).drop(5).mkString(",")
53. res16: String = 2,4,6,8,10
54. scala> x
55. res17: Int = 10
56. scala> x = 0                                             
57. x: Int = 0
58. // define this for-comprehension in a method so that
59. // the repl doesn't call toString on the result value and
60. // as a result force the full list to be processed
61. scala> def add = for( i <- (1 to 10).view ) yield i + inc
62. add: scala.collection.IndexedSeqView[Int,IndexedSeq[_]]
63. scala> add.head                                          
64. res5: Int = 2
65. // for-comprehensions will also be non-strict if the generator is non-strict
66. scala> x
67. res6: Int = 1

This topic introduces the basics of the collections API introduced in Scala 2.8. It is NOT intended to teach everything one needs to know about the collections API. It is intended only to provide context for future discussions about the new features of 2.8 collections. For example I am planning on how to introduce custom collection builders.

Disclaimer: I am not an expert on the changes to 2.8. But I think it is important to have a basic awareness of the changes. So I am going to try to provide a simplified explanation. Corrections are most certainly welcome. I will incorporate them into the post as soon as I get them.

If you want more information you can view the improvement document: Collections SID.

Pre Scala 2.8 there were several criticisms about the inconsistencies on the collections API.

Here is a Scala 2.7 example:

1. scala> "Hello" filter ('a' to 'z' contains _)
2. res0: Seq[Char] = ArrayBuffer(e, l, l, o)
3. scala> res0.mkString("")
4. res1: String = ello

Notice how after the map function the return value is a ArrayBuffer, not a String. The mkString function is required to convert the collection back to a String.
Here is the code in Scala28:

1. scala> "Hello" filter ('a' to 'z' contains _)         
2. res2: String = ello

In Scala28 it recognizes that the original collection is a String and therefore a String should be returned. This sort of issue was endemic in Scala 2.7 and several classes had hacks to work around the issue. For example List overrode the implementations for many of its methods so a List would be returned. But other classes, like Map, did not. So depending on what class you were using you would have to convert back to the original collection type. Maps are another good example:

1. scala> Map(1 -> "one",                                         
2.      |     2 -> "two") map {case (key, value) => (key+1,value)}
3. res3: Iterable[(Int, java.lang.String)] = ArrayBuffer((2,one), (3,two))

But if you use filter in map then you got a Map back.

I don't want to go into detail how this works, but basically each collection is associated with a Builder which is used to construct new instances of the collection. So the superclasses can perform the logic and simply delegate the construction of the classes to the Builder. This has the effect of both reducing the amount of code duplication in the Scala code base (not so important to the API) but most importantly making the return values of the various methods consistent.

It does make the API slightly more complex.

So where in pre Scala 2.8 there was a hierarchy (simplified):

 Iterable[A]
 |
 Collection[A]
 |
 Seq[A]

In 2.8 we now have:

 TraversableLike[A,Repr] 
 / \
 IterableLike[A,Repr] Traversable[A]
 / \ / 
 SeqLike[A,Repr] Iterable[A]
 \ /
 Seq[A]

The *Like classes have most of the implementation code and are used to compose the public facing API: Seq, List, Array, Iterable, etc... From what I understand these traits are publicly available to assist in creating new collection implementations (and so the Scaladocs reflect the actual structure of the code.)