Return value of a block

A common misunderstanding is that a code block (without parameters) is a function. That is not the case. A code block is a sequence of statements that are executed and result the last statement is returned. That sounds like a Function0, however, if the block is passed to a method/function only the last statement will be returned to the function/method. If that method/function expects a function as the parameter the last statement maybe returned as a function not a value, this means that the block itself is not a function.

1. scala> var count = 0                                                                                                                         
2. count: Int = 0
4. // the last statement is returned as a function so count
5. // is incremented only one during the creation of the function
6. scala> List(1,2,3,4).map{count += 1;_ + 1}
7. res9: List[Int] = List(2, 3, 4, 5)
9. scala> count
10. res10: Int = 1
12. // now the count increment is within the function
13. scala> List(1,2,3,4).map{i => count += 1;i + 1}
14. res11: List[Int] = List(2, 3, 4, 5)
16. scala> count
17. res12: Int = 5

The previous example demonstrates a Gotcha if I ever saw one. Map expects a function so the block essentially constructs a function. The last statement being the function. The first line count += 1 executed only once because it is part of creating the function not part of the resulting function. This is equivalent to:

1. scala> val x = {count += 1 ; i:Int => i +1}
2. x: (Int) => Int = < function1>
4. scala> List(1,2,3,4).map(x)
5. res15: List[Int] = List(2, 3, 4, 5)

Beginning a block with the parameter list signals that the entire block is a function.

Rule of thumb: Functions with placeholder parameters should be a single statement.

Type Inference with Abstract Types

A second "gotcha" that one might get tripped up when dealing with abstract types is the signature of the concrete class contains type information about the abstract type. So if you are not explicit when assigning a variable or defining a function you can get unexpected compiler errors.

1. scala> trait S {
2.      |   type x
3.      |   def get : x
4.      | }
5. defined trait S
7. scala> var sample = new S{ 
8.      |   type x = Int
9.      |   def get = 3
10.      | }
11. sample: java.lang.Object with S{type x = Int} = $anon$1@397af435
13. scala> sample = new S {
14.      |   type x = Double
15.      |   def get = 3.0
16.      | }
17. < console>:7: error: type mismatch;
18.  found   : java.lang.Object with S
19.  required: java.lang.Object with S{type x = Int}
20.        sample = new S {

In this example sample uses type inference so the actual type is S with underlying type Int. The consequence is that sample can only be assigned with instances of S with type x = Int. The fix is to explicitly declare the variable type:

1. scala> var sample2 : S = new S{ 
2.      |   type x = Int
3.      |   def get = 3
4.      | }
5. sample2: S = $anon$1@31602bbc
7. scala> sample2 = new S {
8.      |   type x = Double
9.      |   def get = 3.0
10.      | }
11. sample2: S = $anon$1@4de5ed7b

The same thing happens when declaring functions and allows type inference for function definition

1. scala> class Fac {
2.      |   def newS = new S {
3.      |     type x = Int
4.      |     def get = 3
5.      |   }
6.      | }
7. defined class Fac
9. scala> class SubFac extends Fac{
10.      |   override def newS = new S {
11.      |     type x = Double
12.      |     def get = 3.0
13.      |   }
14.      | }
15. < console>:8: error: type mismatch;
16.  found   : java.lang.Object with S
17.  required: java.lang.Object with S{type x = Int}
18.          override def newS = new S {

The fix for this example is to be explicit in the definition of the function in the superclass

Implicit Parameter Resolution

This topic is a continuation of the previous implicit parameter topics:

• Implicit Parameters
• Companion Object Implicits

This topic provides some explanation about how implicit parameters are resulted. There are very strict rules for which implicit value is to be applied to a implicit parameter. A simple way to think about it is that the "closest" definition will be used. Local scope, enclosing class, parent class, companion object of the desired type.

1. class X(val i:Int)
2. class Y(val i:Int)
4. object X {
5.   implicit def xx = new X(1)
6. }
8. class Method {
9.   def x(implicit x:X)=println(x.i)
10.   def y(implicit y:Y)=println(y.i)
11. }
13. trait M { 
14.   self : Method =>
16.   implicit def x1 = new X(10)
17.   implicit def y1 = new Y(100)
19.   def testy = y
20.   def testx = x
21. }
22. trait SM extends M {
23.   self : Method =>
25.   implicit def x2 = new X(20)
26.   implicit def y2 = new Y(200)
27.   
28.   def testy2 = y  
29. }
31. // implicit resolved from companion object of X
32. new Method().x
33. // explicit applied so that value is used
34. new Method().x(new X(3))
35. // implicit resolved from companion object of X
36. // NOT from M.  This is because the call site of x 
37. // is not within M therefore does not use the implicits in M
38. // for resolution.
39. (new Method with M).x
41. implicit def x = new X(30)
42. // local scope overrides companion object implicit
43. new Method().x
44. // explicit applied so that value is used
45. new Method().x(new X(3))
46. // local scope overrides companion object implicit
47. (new Method with M).x
49. // testy is defined within M so the implicits within M
50. (new Method with M).testy
51. // testx is defined within M so the implicit within M
52. // overrides the companion object implicit
53. (new Method with M).testx
54. // testy is within M (not SM) so the implicit within M
55. // is used
56. (new Method with SM).testy
57. // testy2 is within SM so the implicit within SM 
58. // overrides the implicit in M and the companion object
59. (new Method with SM).testy2

Output:

1
3
1
30
3
30
100
10
100
200

Implicit Parameters

Evidently the topic of implicit parameters has not yet been correctly addressed. There have been several topic that refer to implicit parameters but none that directly discuss them. So before I continue with the topic of implicit parameter resolution I will discuss implicit parameters.

First, implicit parameters are not the same as implicit object conversions. Implicit parameters provide a way to allow parameters of a method to be "found". This is similar to default parameters at a glance but in fact is a different mechanism for finding the "default" value. It differs from implicit object conversion in that it is only a way for parameters for a method to be resolved. Implicit object conversion allows methods to appear to be called on one object when in fact that object is being converted behind the scenes to another type. (more or less)

An implicit parameter is a parameter to method or constructor that is marked as implicit. This means that if a parameter value is not supplied then the compiler will search for an "implicit" value defined within scope (according to resolution rules.) Implicit parameter resolution rules will be discussed soon.

Example:

1. scala> def p(implicit i:Int) = print(i)
2. p: (implicit i: Int)Unit
4. // defining a val/var/def as implicit 
5. // means that it will be considered during implicit resolution
6. scala> implicit val v=2
7. v: Int = 2
9. // scope is searched for a implicit value to sue
10. // v is found as marked implicit
11. scala> p               
12. 2
14. // explicit declarations always overrides implicit values
15. scala> p(1)
16. 1

Implicit parameters are very nice for simplifying APIs. For example the collections use implicit parameters to supply CanBuildFrom objects for many of the collection methods. This is because normally the user does not need to be concerned with those parameters. Another example is supplying an encoding to an IO library so the encoding is defined once (perhaps in a package object) and all methods can use the same encoding without having to define it for every method call.

One important restriction is that there can only be a single implicit keyword per method. It must be at the start of a parameter list (which also makes all values of that parameter list be implicit). I further understand that only the last parameter list may be implicit.

Here are several illegal examples:

1. // implicit is not in last parameter list
2. scala> def pp(implicit i:Int, a:Int)(b:Int) = println(a,i)                 
3. < console>:1: error: '=' expected but '(' found.
4.        def pp(implicit i:Int, a:Int)(b:Int) = println(a,i)
6. // there are 2 implicit parameters
7. scala> def pp(implicit j:Int, a:Int)(implicit i:Int,b:Int) = println(a,i)
8. < console>:1: error: '=' expected but '(' found.
9.       def pp(implicit j:Int, a:Int)(implicit i:Int,b:Int) = println(a,i)
11. // implicit is not the first parameter of the parameter list
12. scala> def pp(a:Int, implicit i:Int) = println(i,j)         
13. < console>:1: error: identifier expected but 'implicit' found.
14.        def pp(a:Int, implicit i:Int) = println(i,j)
15.                      ^

Here are several legal examples (Updated with useage examples):

1. scala> implicit def v = 7
2. v: Int
4. scala> implicit var x = 10L
5. x: Long
7. // i is implicit
8. scala> def pp(a:Int)(implicit i:Int) = println(a,i)
9. pp: (a: Int)(implicit i: Int)Unit
11. scala> pp(3)
12. (3,7)
14. // both i and b are implicit
15. scala> def pp(a:Int)(implicit i:Int, b:Long) = println(a,i,b) 
16. pp: (a: Int)(implicit i: Int,implicit b: Long)Unit
18. scala> pp(4)               
19. (4,7,10)
21. // both i and b are implicit
22. scala> def pp(implicit i:Int, b:Long) = println(i,b)  
23. pp: (implicit i: Int,implicit b: Long)Unit
25. scala> pp
26. (7,10)
28. // all or none of the parameters must be supplied
29. scala> pp(2)
30. < console>:13: error: not enough arguments for method pp: (implicit i: Int,implicit b: Long)Unit.
31. Unspecified value parameter b.
32.        pp(2)
34. // This is syntactically legal but I cannot seem to implicitly invoke this
35. // I would recommend: def pp(b:Long*)(implicit i:Int) = println(i,b)
36. scala> def pp(implicit i:Int, b:Long*) = println(i,b)
37. pp: (implicit i: Int,implicit b: Long*)Unit
39. scala> pp(3,1,2,3)
40. (3,WrappedArray(1, 2, 3))
42. scala> def pp(b:Long*)(implicit i:Int) = println(i,b)
43. pp: (b: Long*)(implicit i: Int)Unit
45. scala> pp(1,2,3)
46. (7,WrappedArray(1, 2, 3))

A related topic is Companion Object implicits.

Breaks

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._
5. // pass a function to the breakable method
6. scala> breakable {
7.      | for (i <- 1 to 10 ) {
8.      | if(i > 5) break  // call break when done
9.      | println(i)
10.      | }
11.      | }
12. 1
13. 2
14. 3
15. 4
16. 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
6. // This never ends because break is caught by breakable in the loop method
7. scala> breakable {
8.      | while(true) {
9.      | loop{ i => break; true }
10.      | }
11.      | }

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

Creating Custom Traversable implementations

One of the most talked about features of Scala 2.8 is the improved Collections libraries. Creating your own implementation is trivial, however if you want your new collection to behave the same way as all the included libraries there are a few tips you need to be aware of.

Note: All of these examples can either be ran in the REPL or put in a file and ran

Starting with the simple implementation:

1. import scala.collection._
2. import scala.collection.generic._
4. class MyColl[A](seq : A*) extends Traversable[A] {
5.     // only abstract method in traversable is foreach... easy :) 
6.   def foreach[U](f: A => U) = util.Random.shuffle(seq.toSeq).foreach(f)
7. }

This is a silly collection I admit but it is custom :).

This example works but if you test the result of a map operation (or any other operation that returns a new instance of the collection) you will notice it is not an instance of MyColl. This is expected because unless otherwise defined Traversable will return a new instance of Traversable.

To demonstrate run the following tests:

1. val c = new MyColl(1, 2, 3)
2. println (c mkString ",")
3. println(c mkString ",")
5. println(c drop 1 mkString ",")
7. // this two next assertions fail (see following explanation)
8. assert(c.drop(1).isInstanceOf[MyColl[_]])
9. assert((c map {_ + 1}).isInstanceOf[MyColl[_]])

Both assertions will fail. The reason for these failures is because the collection is immutable which dictates by necessity that a new object must be returned from filter/map/etc... Since the Traversable trait returns instances of Traversable these two assertions fail. The easiest way to make these methods return an instance of MyColl is to make the following changes/additions.

1. import scala.collection._
2. import scala.collection.generic._
4. /*
5. Adding GenericTraversableTemplate will delegate the creation of new
6. collections to the companion object.  Adding the trait and
7. companion object causes all the new collections to be instances of MyColl
8. */
9. class MyColl[A](seq : A*) extends Traversable[A] 
10.                              with GenericTraversableTemplate[A, MyColl] {
11.   override def companion = MyColl
12.   def foreach[U](f: A => U) = util.Random.shuffle(seq.toSeq).foreach(f)
13. }
15. // The TraversableFactory trait is required by GenericTraversableTemplate
16. object MyColl extends TraversableFactory[MyColl] {
17. /* 
18. If you look at the signatures of many methods in TraversableLike they have an
19. implicit parameter canBuildFrom.  This allows one to define how the returned collections
20. are built.  For example one could make a list's map method return a Set
21. In this case we define the default canBuildFrom for MyColl
22. */
23.   implicit def canBuildFrom[A]: CanBuildFrom[Coll, A, MyColl[A]] = new GenericCanBuildFrom[A]
24. /*  
25. The method that builds the new collection.  This is a simple implementation
26. but it works.  There are other implementations to assist with implementation if
27. needed
28. */
29.   def newBuilder[A] = new scala.collection.mutable.LazyBuilder[A,MyColl[A]] {
30.     def result = {
31.       val data = parts.foldLeft(List[A]()){(l,n) => l ++ n}
32.       new MyColl(data:_*)
33.     }
34.   }
35. }

Now instances of MyColl will be created by the various filter/map/etc... methods and that is fine as long as the new object is not required at compile-time. But suppose we added a method to the class and want that accessible after applying methods like map and filter.

Adding val o : MyColl[Long] = c map {_.toLong} to the assertions will cause a compilation error since statically the class returned is Traversable[Long]. The fix is easy.

All that needs to be done is to add with TraversableLike[A, MyColl[A]] to MyColl and we are golden. There may be other methods as well but this works and is simple.

Note that the order in which the traits are mixed in is important. TraversableLike[A, MyColl[A]] must be mixed in after Traversable[A]. The reason is that we want methods like map and drop to return instances of MyColl (statically as well as dynamically). If the order was reversed then those methods would return Traversable event though statically the actual instances would still be MyColl.

1. import scala.collection._
2. import scala.collection.generic._
4. class MyColl[A](seq : A*) extends Traversable[A]
5.                              with GenericTraversableTemplate[A, MyColl] 
6.                              with TraversableLike[A, MyColl[A]] {
7.   override def companion = MyColl
8.   def foreach[U](f: A => U) = util.Random.shuffle(seq.toSeq).foreach(f)
9. }
11. object MyColl extends TraversableFactory[MyColl] {  
12.   implicit def canBuildFrom[A]: CanBuildFrom[Coll, A, MyColl[A]] = new GenericCanBuildFrom[A]
13.   def newBuilder[A] = new scala.collection.mutable.LazyBuilder[A,MyColl[A]] {
14.     def result = {
15.       val data = parts.foldLeft(List[A]()){(l,n) => l ++ n}
16.       new MyColl(data:_*)
17.     }
18.   }
19. }

Now add in a new method to demonstrate that the new collection works as desired and we are done.

The following is the complete implementation with the tests. You can put it in a file and run scala <filename> or paste it into a REPL

1. import scala.collection._
2. import scala.collection.generic._
3. import scala.collection.mutable.{ Builder, ListBuffer }
5. class MyColl[A](seq : A*) extends Traversable[A]
6.                              with GenericTraversableTemplate[A, MyColl] 
7.                              with TraversableLike[A, MyColl[A]] {
8.   override def companion = MyColl
9.   def foreach[U](f: A => U) = util.Random.shuffle(seq.toSeq).foreach(f)
11.   def sayhi = println("hi!")
12. }
14. object MyColl extends TraversableFactory[MyColl] {  
15.   implicit def canBuildFrom[A]: CanBuildFrom[Coll, A, MyColl[A]] = new GenericCanBuildFrom[A]
16.   def newBuilder[A] = new ListBuffer[A] mapResult (x => new MyColl(x:_*))
17. }
19. val c = new MyColl(1, 2, 3)
20. println (c mkString ",")
21. println(c mkString ",")
23. assert(c.drop(1).isInstanceOf[MyColl[_]])
24. assert((c map {_ + 1}).isInstanceOf[MyColl[_]])
26. val o : MyColl[Int] = c filter {_ < 2}
27. println(o mkString "," )
28. o.sayhi

Elidable (remove method calls at compile time)

In Scala 2.8 there is a useful annotation called 'elidable'. This annotation flags a method so that given certain compiler flags all calls to the method will be removed. This is handy if you are writing a logger. The log methods can be annotated so that when compiling for production all log calls below a certain level would be removed from the compiled code. Several of the methods in Predef are annotated with elidable. Specifically, assume, assert and require.

The elidable annotation takes an Int parameter which specifies the priority of the method. The lower the integer the more likely the method would be removed during compilation. The elidable object defines several values that are used in our example.

When compiling with the -Xelide-below , the compiler parameter will remove all calls to elidable methods value and below.

To try the following example copy the example into a scala file (elidable.scala for example) and compile as indicated below:

1. package example
3. import scala.annotation.elidable
4. import scala.annotation.elidable._
6. object ElidableExamples {
7.     @elidable(ALL) def all = println("all")
8.     @elidable(ASSERTION) def assertion = println("assertion")
9.     @elidable(CONFIG) def config = println("config")
10.     @elidable(FINE) def fine = println("fine")
11.     @elidable(FINER) def finer = println("finer")
12.     @elidable(FINEST) def finest = println("finest")
13.     @elidable(INFO) def info = println("info")
14.     @elidable(OFF) def off = println("off")
15.     @elidable(SEVERE) def severe = println("severe")
16.     @elidable(WARNING) def warning = println("warning")
17. }
19. object Main extends Application {
20. println("starting")
21. import ElidableExamples._
22. all
23. assertion
24. config
25. fine
26. finer
27. finest
28. info
29. off
30. severe
31. warning
32. println("ending")
34. assert(false, "boom!")
35. }

Output from scalac elidable.scala && scala example.Main

starting
assertion
off
ending
java.lang.AssertionError: assertion failed: boom!
at scala.Predef$.assert(Predef.scala:93)
at example.Main$.(elidable.scala:34)
at example.Main$.(elidable.scala)
at example.Main.main(elidable.scala)

Output from scalac -Xelide-below 0 elidable.scala && scala example.Main

starting
assertion
config
fine
finer
finest
info
off
severe
warning
ending
java.lang.AssertionError: assertion failed: boom!
at scala.Predef$.assert(Predef.scala:93)
at example.Main$.(elidable.scala:34)
at example.Main$.(elidable.scala)
at example.Main.main(elidable.scala)

Output from scalac -Xelide-below 1000 elidable.scala && scala example.Main

starting
assertion
off
severe
ending
java.lang.AssertionError: assertion failed: boom!
at scala.Predef$.assert(Predef.scala:93)
at example.Main$.(elidable.scala:34)
at example.Main$.(elidable.scala)
at example.Main.main(elidable.scala)

Output from scalac -Xelide-below 3000 elidable.scala && scala example.Main

starting
off
ending

Variant Positions 3

The last few topics all discussed variance in its different forms. The following is a cheat sheet of the where the different variances exist within a class.

See Variant positions 1 for a discussion on one position in a class that is a contravariant position.

The example is:

1. scala> class Output[+A] {def write(a : A) = () /*do write*/ }

In this example A in the method write is an contravariant position. Which means the previous definition is not legal because A is defined as Covariant in the class definition. In a class there are several positions with different variance characteristics. Here's the example from Programming in Scala:

1. abstract class Cat[-T, +U] { 
2.     def meow[W^-](volume: T^-, listener: Cat[U⁺, T^-]^-): Cat[Cat[U⁺, T^-]^-, U⁺]⁺
3. }

If you remove the superscript + and - the above example actually compiles. The + and - indicate if the position is a covariant or contravariant position. Its not critical to memorize the positions (in my opinion). Just look it up as needed. The rule of thumb is that each nested position is inverted (flipped) value of it enclosing position.

That is all I will say about that :)

Variant Positions 2

This is a continuation of post: Variant Positions 1

...

My first attempt at the Verified was to make it a mutable object (my Java tourettes kicking in). But it cannot be covariant and mutable. Look at the code to see why:

1. class Verified[+A <: V,V](assertion : (V) => Boolean, private var value : A){
2.     assert(assertion(value))
3.     
4.     def a = value
5. // update is illegal.  See the example below
6.     def update[ B >: A <: V](a : B) = value = a
7. }
9. def notNull(obj : AnyRef) = obj != null
10. val v = new Verified(notNull, "hi")
12. /*
13. Up to this point everything looks ok but the next line
14. will assign an object to value which is a reference to a String
15. */
16. v update (new Object())

For Verified to be mutable A must be invariant. If you look at the Mutable collections in Scala they are all invariant.

Here is an interesting example of both invariant and covariant type parameters in a class hierarchy:

1. scala> class X[+A](val x :A)
2. defined class X
4. scala> class Y[A](var a: A) extends X[A](a)
5. defined class Y
7. scala> val x: X[Any] = new Y[String]("hi")
8. x: X[Any] = Y@1732a4df
10. scala> x.asInstanceOf[Y[String]].a="ho"

This example is perfectly legal because no matter how X[Any] is used no illegal assignment in Y can occur. The interesting thing is that the object can be used in covariant usecases when only X is required. This is now the collections in Scala can work.

Here is a little example of collections invariance and covariance in action. In List the parameter is covariant but in Buffer it is invariant

1. scala> def printList(l : List[Any]) = print(l mkString " :: ")
2. printList: (l: List[Any])Unit
4. scala> val buffer = Buffer(1,2,3)
5. buffer: scala.collection.mutable.Buffer[Int] = ArrayBuffer(1, 2, 3)
7. scala> printList(buffer)
8. 1 :: 2 :: 3
10. /*
11. ++ is part of Iterable.  Since Iterable is covariant ++ 
12. returns a new buffer it does not modify the existing buffer
13. All mutators are only defined on invariant traits
14. */
15. scala> buffer ++ List(4)
16. res16: scala.collection.mutable.Buffer[Int] = ArrayBuffer(1, 2, 3, 4)
18. scala> res16 eq buffer
19. res17: Boolean = false
21. /*
22. buffer defines += to add an element to the buffer
23. so res27 is the same buffer with an extra element
24. */
25. scala> buffer += 10
26. res27: buffer.type = ArrayBuffer(1, 2, 3, 10)
28. scala> res27 eq buffer
29. res28: Boolean = true

Variant Positions 1

An additional topic on variance to finish up the major points on the topic. The previous two posts:

• In- and Co- variance of type parameters
• Contravariance

contain required information for following this post.

In-, co- and contra- variance are the three types of variance expressible in Scala. I showed how this affects assignments and arguments being pass to methods in the last two topics. This looks at how the different types of variance influences how classes can be defined. In the last post we saw how the compiler complained about a method definition in a covariant class because the compiler recognized that such a definition was inherently dangerous and must be prohibited. The example was:

1. scala> class Output[+A] {def write(a : A) = () /*do write*/ }
2. < console>:5: error: covariant type A occurs in contravariant position in type A of value a
3.        class Output[+A] {def write(a : A) = () /*do write*/ }
4.                                    ^

For an class like Output it does not make sense to have A be covariant so we changed A to be contravariant. However suppose we have a collection type class.

1. class Verified[+A] (assertion : (A) => Boolean, value : A){
2.     assert(assertion(value))
3.     
4.     def a = value
5.     def a_=(a : A) = new Verified(assertion, a)
6. }

The previous definition is not legal because value and a in the parameter of a_= "occur in a contravariant position." What to do? Making A contravariant isn't an option:

1. class Verified[+A <: V,V](assertion : (V) => Boolean, val value : A){
2.     assert(assertion(value))
3. /*
4. this is the key.  Restrict possible types of
5. A Since B is a super (or equal) type of A
6. */
7.     def update[ B >: A <: V](a : B) = new Verified(assertion, a)
8. }
10. // example useage
11. scala> def notNull(obj : AnyRef) = obj != null
12. notNull: (obj: AnyRef)Boolean
14. scala> val v = new Verified(notNull, "hi")
15. v: Verified[java.lang.String,AnyRef] = Verified@307b37df
17. scala> val newV = v update (new Object())
18. newV: Verified[java.lang.Object,AnyRef] = Verified@36f72f09
20. // 3 is not legal because the type parameter 'V' is AnyRef.  Int is a subclass of Any NOT AnyRef
21. scala> val newV = v update (3)           
22. < console>:8: error: inferred type arguments [Any] do not conform to method update's type parameter bounds [B >: java.lang.String <: AnyRef]
23.        val newV = v update (3)
24.                   ^

Contravariance

Continuing on with variance and type parameters, this topic will discuss contravariance. See the post In- and Co- variance of type parameters for the intro material required for this topic.

Covariant parameters allow for an additional dimension of type compatibility:

1. val l : List[Object] = List("this is legal")

Contravariance provides the opposite:

1. // If the type parameter of list was contravariant this would be legal:
2. val l : List[String] = List(new Object())

As covariance is indicated by a '+' before the type contravariance is indicated by a '-'

1. scala> class X[-A]
2. defined class X
4. scala> val l : X[String] = new X[Object]
5. l: X[String] = X@66201d6d

I can almost hear the "cool... but why?". Following the lead in the Programming In Scala book. Consider OutputStream first and a method in a Collection second. (The following code is illegal but consider it)

1. class Output[+A] {def write(a : A) = () /*do write*/ }
3. def writeObject(out : Output[Object]) = out.write("hello")
5. /*
6. Uh oh you this only is for outputting lists not Objects 
7. (certainly not the String that is actually written)
9. Runtime error for sure!
10. */
11. writeObject(new Output[List[String]])

The previous example (if it would compile) would explode because an Output that can only write lists is passed to the method. In the example a String is written to the Output object. The Output[List[String]] cannot handle that.

Fortunately the compiler sees the definition of the class and recognizes this is an error waiting to happen and makes it illegal:

1. scala> class Output[+A] {def write(a : A) = () /*do write*/ }
2. < console>:5: error: covariant type A occurs in contravariant position in type A of value a
3.        class Output[+A] {def write(a : A) = () /*do write*/ }
4.                                    ^

Consider the implications of making A contravariant?

1. // The definition of object is now legal
2. class Output[-A] {def write(a : A) = () /*do write*/ }
4. // this is now a safe method definition since the parameter of Output must be a Object or a super class
5. def writeObject(out : Output[Object]) = out.write("hello")
7. // Now this is illegal as it should be
8. scala> writeObject(new Output[List[String]])
9. < console>:8: error: type mismatch;
10.  found   : Output[List[String]]
11.  required: Output[java.lang.Object]
12.        writeObject(new Output[List[String]])
13.        
14. // this is legal... 
15. scala> writeObject(new Output[Any])

In this example Output[Any] can be passed to the method. This makes sense. If the Output object knows how to write Any oject then it knows how to write an Object; its all good.

Implicit '=' operator

Continuing on with operators, There is a special type of operator in Scala. It is an operator that ends with =. If a class has operation (methods with an operator identifer) the = can be appended to the effectively creating a new method. In truth a new method is not created instead the compiler rewrites the line.

For example. If a method (like Int) defines + then a method call += can be used. It can be used to mutate a variable:

1. scala> var i = 1
2. i: Int = 1
4. scala> i += 1
6. scala> i
7. res3: Int = 2

To illustrate this is not a special case for Int the next example defines several operations and demonstrates in place variable mutation.

1. scala> case class MyClass(i:Int) {      
2.      | def +(j:Int) = new MyClass(j + i)
3.      | def -(j:Int) = new MyClass(i - j)
4.      | def ^(j:Int) = MyClass(j)
5.      | def +|(j:Int) = new MyClass(j + i / 3)
6.      | }
7. defined class MyClass
9. scala> var c = MyClass(1)
10. c: MyClass = MyClass(1)
12. scala> c+=6
14. scala> c
15. res5: MyClass = MyClass(7)
17. scala> c -= 2
19. scala> c
20. res7: MyClass = MyClass(5)
22. scala> c ^= 10
24. scala> c
25. res23: MyClass = MyClass(10)
27. scala> c +|= 5
29. scala> c
30. res25: MyClass = MyClass(8)

Here are several more examples using existing classes in Scala. They are all immutable examples.

1. scala> var l = Set(1,2,3) 
2. l: scala.collection.immutable.Set[Int] = Set(1, 2, 3)
4. scala> l += 10
6. scala> l
7. res7: scala.collection.immutable.Set[Int] = Set(1, 2, 3, 10)
9. scala> var seq = Seq(5,6,3)
10. seq: Seq[Int] = List(5, 6, 3)
12. scala> seq :+= 10
14. scala> seq                 
15. res9: Seq[Int] = List(5, 6, 3, 10)
17. scala> seq +:= 10   
19. scala> seq       
20. res11: Seq[Int] = List(10, 5, 6, 3, 10)
22. scala> var list = List(32)
23. list: List[Int] = List(32)
25. scala> list ::= 12
27. scala> list
28. res13: List[Int] = List(12, 32)

Note: assignment operators can also be defined as methods to mutate an object

1. scala> case class MyClass(var i:Int) {
2.      | def += (j:Int) = { i+=j ; this }
3.      | }
4. defined class MyClass
6. scala> val m = MyClass(6)
7. m: MyClass = MyClass(6)
9. scala> m += 7
10. res0: MyClass = MyClass(13)
12. scala> m += 9
13. res1: MyClass = MyClass(22)
15. scala> res1 eq m
16. res2: Boolean = true

Geoscript.scala

This is a bit of a departure from the standard daily-scala format, but it is one of the elements I had always invisioned. This topic takes a look at Geoscript.scala. (Github repo is at: http://github.com/dwins/geoscript.scala)

Geoscript has been given a Scala implementation. It is based on the Geotools Java library and thus far provides a script interface to access some of the basic spatial functions.

For setting up the console with the required libraries follow the instructions at: http://geoscript.org/scala/quickstart.html#quickstart

Here is an example of Geoscript in action:

1. scala> import org.geoscript.GeoScript._
2. import org.geoscript.GeoScript._
4. scala> import org.geoscript.geometry._
5. import org.geoscript.geometry._
7. scala> val line = LineString((10, 10), (20, 20), (30, 40))
8. line: org.geoscript.geometry.LineString = LINESTRING (10 10, 20 20, 30 40)
10. /*
11. create a polygon by buffering the line (essentially expanding the line by 10 units that is degrees if not otherwise specified)
12. */
13. scala> val poly = line buffer 10
14. poly: org.geoscript.geometry.Geometry = POLYGON ((11.781455848733053 25.923591472464004, 21.05572809000084 44.47213595499958, 22.100060210309515 46.13114600374718, 23.447982586398712 47.55453954995706, 25.04769531727891 48.68761637789669, 26.837722339831622 49.48683298050514, 28.74927391943886 49.921475911950004, 30.708890200906794 49.97484208812642, 32.64126422950409 49.6448806768120...
16. // query the area of the polygon
17. scala> poly.area
18. res0: Double = 1041.9912814842407
20. // get the centroids of the polygon and line
21. scala> line.centroid
22. res1: org.geoscript.geometry.Point = POINT (21.12574113277207 24.188611699158105)
24. scala> poly.centroid
25. res2: org.geoscript.geometry.Point = POINT (20.79088988611118 24.43096430943361)
28. /*
29. Obviously the polygon and line intersect since the polygon is a buffer of the line
30. */
31. scala> poly.intersects(line)
32. res3: Boolean = true
34. scala> val poly2 = Geometry.fromWKT("POLYGON ((10 10, 10 20, 20 20, 20 15, 10 10))")
35. poly2: org.geoscript.geometry.Geometry = POLYGON ((10 10, 10 20, 20 20, 20 15, 10 10))
37. // less trivial intersects operation
38. scala> poly intersects poly2
39. res3: Boolean = true
41. // not make a new geometry from the intersection of the two geometries
42. scala> val intersecting = poly intersection poly2
43. intersecting: org.geoscript.geometry.Geometry = POLYGON ((10 10, 10 20, 20 20, 20 15, 10 10))
45. scala> intersecting.area 
46. res6: Double = 75.0
49. scala> import org.geoscript.projection._
50. import org.geoscript.projection._
52. /*
53. None of the previous geometries has a projection associated.  
54. A new geometry can have one created with a projection by using the in(Projection) method
55. */ 
56. scala> val latLongPoly = poly2 in Projection("epsg:4326")
57. latLongPoly: org.geoscript.geometry.Geometry = POLYGON ((10 10, 10 20, 20 20, 20 15, 10 10))
59. // now reproject the latlong projection to a french projection 
60. scala> latLongPoly in Projection("epsg:21781")
61. res12: org.geoscript.geometry.Geometry = POLYGON ((950650.7690658928 -4203986.192880551, 900363.7533498043 -2900002.601715782, 2061411.5566836582 -2774908.8442438124, 2174910.791185147 -3393231.5380846346, 950650.7690658928 -4203986.192880551))

Multiple Argument Implicit Conversions

Suppose you are creating a DSL and you want to implicitly convert 2 values to a particular object:

1. val v : SomeObject = (2, 3)

This is easily attained. In this example we will support the previous example as well as the standard 1 object to another implicit conversion.

1. val v : SomeObject = 2

Example:

1. // first lets define a class
2. scala> case class Randomly(x : Int, y : Double)
3. defined class Randomly
5. // the normal conversion
6. scala> implicit def intToRandomly(i : Int) = new Randomly(i,0.0)
7. intToRandomly: (i: Int)Randomly
9. /*
10. now a tuple for the other conversion.
12. Important:  The two conversions must have different names. At least that is the case in Scala 2.8
13. */
14. scala> implicit def tupleToRandomly(i : (Int, Double)) = new Randomly(i._1, i._2)
15. tupleToRandomly: (i: (Int, Double))Randomly
16.  
17. scala> val r1 : Randomly = 4                                                     
18. r1: Randomly = Randomly(4,0.0)
20. scala> val r2 : Randomly = (4, 6.0)
21. r2: Randomly = Randomly(4,6.0)
24. /*
25. Suppose you want to do
26. val r : Randomly = (4,4)
28. you might think to implicitly convert from in to double
29. */
30. scala> implicit def intToDouble(i : Int) = i.toDouble
31. intToDouble: (i: Int)Double
33. // implicit chaining is not permitted
34. scala> val r3 : Randomly = (4, 6)                    
35. < console>:10: error: type mismatch;
36.  found   : (Int, Int)
37.  required: Randomly
38.        val r3 : Randomly = (4, 6)
40. // Here is the legal option
41. scala> implicit def intTupleToRandomly(t: (Int,Int)) = new Randomly(t._1,t._2.toDouble) 
42. intTupleToRandomly: (t: (Int, Int))Randomly
44. scala> val r3 : Randomly = (4, 6)                                                      
45. r3: Randomly = Randomly(4,6.0)