How to reverse a map

Suppose you wish to take a map and swap the keys with values. The stackoverflow question Elegant way to revers a map in scala offers some good suggestions

1. scala> val nodupes = Map(1 -> "a", 2-> "b", 3 -> "c")
2. nodupes: scala.collection.immutable.Map[Int,java.lang.String] = Map((1,a), (2,b), (3,c))
4. // Scala 2.8+
5. scala> nodupes map {_.swap}                          
6. res4: scala.collection.immutable.Map[java.lang.String,Int] = Map((a,1), (b,2), (c,3))
8. // Scala 2.7
9. scala> Map() ++ (nodupes map {case (k,v) => (v,k)})  
10. res5: scala.collection.immutable.Map[java.lang.String,Int] = Map((a,1), (b,2), (c,3))
12. // watch out if the values have duplicates you will loose information:
13. scala> val dupes = Map(1 -> "a", 2-> "b", 3 -> "b")  
14. dupes: scala.collection.immutable.Map[Int,java.lang.String] = Map((1,a), (2,b), (3,b))
16. scala> dupes map {_.swap}                          
17. res6: scala.collection.immutable.Map[java.lang.String,Int] = Map((a,1), (b,3))
19. // a way to not loose any data
20. scala> dupes groupBy {_._2} map {case (key,value) => (key, value.unzip._1)}     
21. res12: scala.collection.Map[java.lang.String,scala.collection.immutable.Iterable[Int]] = Map((a,List(1)), (b,List(2, 3)))
24. // I wanted to do the following for performance:
25. scala> dupes.view groupBy {_._2} map {case (key,value) => (key, value.unzip._1)}
26. java.lang.UnsupportedOperationException: IterableView((1,a), (2,b), (3,b)).newBuilder
27. at scala.collection.TraversableViewLike$class.newBuilder(TraversableViewLike.scala:40)
28. at scala.collection.IterableLike$$anon$1.newBuilder(IterableLike.scala:363)
29. at scala.collection.TraversableLike$$anonfun$groupBy$1.apply(TraversableLike.scala:370)
31. // but as you can see a view cannot yet be grouped.  Perhaps in the future.

Lazy man's random test data

A quick tip for generating some random testdata.

Note: This is a poor man's solution to using ScalaCheck. If you can handle the dependency I would really recommend using that library.

1. scala> object Options extends Enumeration {                       
2.      | val ONE, TWO, THREE, FOUR = Value                          
3.      | }
4. defined module Options
6. /*
7. Randomly select zero or more elements from the options enumeration
8. */
9. scala> Options.values.filter {_ => util.Random.nextBoolean} mkString ", "
10. res2: String = TWO, FOUR
12. /*
13. Select a random string.  
15. Warning:  there is no restriction on the characters so control characters are likely
16. */
17. scala> util.Random.nextString(10)
18. res5: String = ??????????
20. /*
21. ASCII string is oftern more useful for test data.  This selects a random string up to 13 characters long
22. */
23. scala> util.Random.nextASCIIString(13)
24. res6: java.lang.String = RVPD\#_HqJ8:o
26. /*
27. This creates a sequence of 10 random strings
28. */
29. scala> 1 to 10 map {_ => util.Random.nextASCIIString(13)}
30. res7: scala.collection.immutable.IndexedSeq[java.lang.String] = IndexedSeq(;E8|Q8H8RI;Q=, vM-X;"ksBr\:c, SKyz{uXNQ5E]X, =Jd8_ll08)s%e, gRCs)6wj%C-YF, `x;2Zru?l*c%@, XE*/Rx9:qPfpm, s|u,e.un+-Xm(, M,TpX9Dq-6$+^, w;exER&#0|}Ya)

Blocks within if statements

his is another topic that examines the consistency of Scala. This topic examines blocks in if statements. It is related to Blocks within for comprehensions and Temporary Variables during object creation.

1. // standard if
2. if(1 > 2) -1 else 0
4. // since blocks return a value you can use a block within the if statement 
5. // (not sure when you would want to but...)
6. if ({ val x = 1
7.       val y = 2
8.       x == y }) 1 else 2

Zip with a constant value

A simple tip for zipping a List (or other collection) with a single value.

1. scala> Stream.continually("h") zip List(1,2,3,4)
2. res2: scala.collection.immutable.Stream[(java.lang.String, Int)] = Stream((h,1), ?)
4. scala> res2 mkString ","
5. res3: String = (h,1),(h,2),(h,3),(h,4)
7. scala> List(1,2,3,4) zip Stream.continually("h")
8. res4: List[(Int, java.lang.String)] = List((1,h), (2,h), (3,h), (4,h))

Functions using case statements

A further tip regarding using case statements to construct functions. If a case statement is assigned to a Function it will construct a Function object not a PartialFunction.

I suppose the question is why do you care about this since PartialFunction is a Function. The fact is that a PartialFunction is a Function1. But using a case statement you can construct a Function4 very easily.

1. scala> def run(f : Function1[Any,Unit]) = println(f.isInstanceOf[PartialFunction[_,_]])
2. run: (f: (Any) => Unit)Unit
4. /*
5. since run expects a Function calling run as shown here will make a 
6. Function object not a PartialFunction Object
7. */
8. scala> run({case f => ()}) 
9. false
11. scala> def pf(f : PartialFunction[Any,Unit]) = println(f.isInstanceOf[PartialFunction[_,_]]) 
12. pf: (f: PartialFunction[Any,Unit])Unit
14. // Now a PartialFunction will be created
15. scala> pf({case f => ()})                                                                         
16. true
18. scala> def run(f : Function2[Int,String,Unit]) = f(1,"2")                                     
19. run: (f: (Int, String) => Unit)Unit
21. /*
22. This demonstrates why it is important that a case creates a Function
23. when assigned to a Function. PartialFunctions are Function1 objects
24. but the following statement is creating a Function2 object.
25. */
26. scala> run({                 
27.      | case (1,b) => println(b)
28.      | case (a,b) => println(a,b)
29.      | })
30. 2

Methods on PartialFunction

This topic inspects the methods defined in the PartialFunction Object.

1. scala> type PF = PartialFunction[Int,Int]
2. defined type alias PF
4. // the two partial functions that we will use for the examples
5. scala> val pf1 : PF = {case 1 => 2}                      
6. pf1: PF = < function1>
8. scala> val pf2 : PF = {case 2 => 3}                      
9. pf2: PF = < function1>
11. /*
12. As is well known, when a PartialFunction is called with a value
13. it must be defined at that value or bad things will happen
14. */
15. scala> pf1 isDefinedAt 1  
16. res14: Boolean = true
18. scala> pf1 isDefinedAt 2
19. res15: Boolean = false
21. scala> pf1(2)
22. scala.MatchError: 2
23. at $anonfun$1.apply(< console>:5)
24. at $anonfun$1.apply(< console>:5)
25. at .< init>(< console>:7)
26.     ...
27. scala> pf1(1)
28. res5: Int = 2
30. /*
31. It is possible to compose two partial functions so first one partialFunction is called and then the next
32. */
33. scala> (pf1 andThen pf2) isDefinedAt 2 
34. res16: Boolean = false
36. scala> (pf1 andThen pf2) isDefinedAt 1
37. res17: Boolean = true
39. scala> (pf1 andThen pf2)(2)
40. scala.MatchError: 2
41. at $anonfun$1.apply(< console>:5)
42. at $anonfun$1.apply(< console>:5)
43. at scala.PartialFunction$$anon$2.apply(PartialFunction.scala:59)
44. at .< init>(< console>:8)
45.     ...
46. scala> (pf1 andThen pf2)(1)
47. res8: Int = 3
49. /*
50. An alternative way of combining PartialFunctions is to 'or' them
51. */
52. scala> (pf1 orElse pf2) isDefinedAt 1
53. res18: Boolean = true
55. scala> (pf1 orElse pf2) isDefinedAt 2
56. res19: Boolean = true
58. scala> (pf1 orElse pf2) isDefinedAt 3
59. res20: Boolean = false
61. scala> (pf1 orElse pf2)(1) 
62. res9: Int = 2
64. scala> (pf1 orElse pf2)(2)
65. res10: Int = 3
67. /*
68. Finally a PartialFunction can be easily converted to a function that returns 
69. an Option
70. */
71. scala> pf1.lift
72. res21: (Int) => Option[Int] = < function1>
74. scala> pf1.lift(1)
75. res11: Option[Int] = Some(2)
77. scala> pf1.lift(2)
78. res12: Option[Int] = None

NullPointer when mixed traits (Warning)

This tip is mainly to document a 'GOTCHA' that I got caught by recently. It basically goes like this:

Trait Y extends(or has self-type) X. Trait X defines some abstract method 'm'. The initialization code in Y accesses 'm'. Creation of an object new X with Y results in: *Boom* NullPointerException (on object creation).

The example in code:

1. scala> trait X { val x : java.io.File }
2. defined trait X
4. scala> trait Y {self : X => ; val y = x.getName} 
5. defined trait Y
7. scala> new X with Y { val x = new java.io.File("hi")}
8. java.lang.NullPointerException
9. at Y$class.$init$(< console>:5)
10. at $anon$1.< init>(< console>:7)
11. ...

At a glance it seems that x should override the abstract value x in trait X. However the order in which traits are declared is important. In this case first Y is configured then X. Since X is not yet configured Y throws an exception. There are several ways to work around this.
Option 1:

1. trait X {val x : java.io.File}
2. trait Y {self : X => ; val y = x.getName}
3. /*
4. Declaring Y with X will work because Y is initialized after X
5. but remember that there may
6. be other reasons that X with Y is required.  
8. Method resolution is one such reason
9. */
10. new Y with X { val x = new java.io.File("hi")}

Option 2:

1. trait X { val x : java.io.File }
2. trait Y {self : X => ; def y = x.getName}
3. /*
4. Since method y is a 'def' x.getName will not be executed during initialization.
5. */
6. scala> new X with Y { val x = new java.io.File("hi")}
7. res10: java.lang.Object with X with Y = $anon$1@7cb9e9a3

Option 3:

1. trait X { val x : java.io.File }
2. trait Y {self : X => ; lazy val y = x.getName}
3. /*
4. 'lazy val' works for the same reason 'def' works: x.getName is not invoked during initialization
5. */
6. scala> new X with Y { val x = new java.io.File("hi")}
7. res10: java.lang.Object with X with Y = $anon$1@7cb9e9a3

Option 4:

1. trait X {val x : java.io.File }
2. trait Y extends X {def y = x.getName}
3. /*
4. if Y extends X then a new Y can be instantiated
5. */
6. new Y {val x = new java.io.File("hi")}

Two more warnings. First, the same error will occur whether 'x' is a def or a val or a var.

1. trait X { def x : java.io.File }   
2. trait Y {self : X => ; val y = x.getName}     
3. new X with Y { val x = new java.io.File("hi")}

Second warning: In complex domain models it is easy to have a case where Y extends X but the final object is created as: new X with Y{...}.

You will get the same error here because (I think) the compiler recognized that Y is being mixed in with X and therefore the X will be initialized as after Y instead of before Y.

First the code:

1. trait X { def x : java.io.File }   
2. trait Y extends X { val y = x.getName}        
3. new X with Y { val x = new java.io.File("hi")}

If the code instantiated new Y{...} the initialization would be X then Y. Because X can only be initialized once, the explicit declaration of new X with Y forces Y to be initialized before X. (X can only be initialized once even when it appears twice in the hierarchy).

This is a topic called linearization and will be addressed in the future.