Instance Type (Abstract type gotcha 1)

In a previous post about abstract types I showed one of the benefits of using abstract types over parameterized types. Abstract Types vs Parameter. The next several posts will feature potential problems you may encounter when using Abstract Types.

I should point out that abstract types are not inherently difficult to understand but they are rather different from anything you will see when you come from the Java world so if you are new to them I would use them with caution at first.

In the abstract types example you will notice that the abstract type 'I' in Foreach is not within the trait Source rather it is outside in the Foreach trait. At first one might consider putting the type in Source rather than Foreach. The naive change can get you in trouble (but there is a couple easy fixes)

1. trait Foreach[A] {
2.   trait Source {
3.     type I <: java.io.Closeable  // moved this line into Source
4.     def in : I
5.     def next(in : I) : Option[A]
6.   }
7.   def source : Source
8.   
9.   def foreach[U](f : A => U) : Unit = {
10.     val s = source.in
11.     try {
12.       def processNext : Unit = source.next(s) match {
13.         case None => 
14.           ()
15.         case Some(value) => 
16.           f(value)
17.           processNext
18.       }
19.       
20.       processNext
21.     } finally {
22.       // correctly handle exceptions
23.       s.close
24.     }
25.   }
26. }

Compiling the class results in a compilation error:

jeichar: tmp$ scalac XX.scala
XX.scala:12: error: type mismatch;
found : s.type (with underlying type Foreach.this.Source#I)
required: _2.I where val _2: Foreach.this.Source
def processNext : Unit = source.next(s) match {
^
XX.scala:16: error: type mismatch;
found : value.type (with underlying type Any)
required: A
f(value)
^
two errors found

So what is the problem? The problem is simple but subtle. Notice that source is defined as a def. So calling source 2 times may return 2 different instances of Source. A simple change can fix this. Either change def source : Source to val source : Source. Or change the method foreach to assign the result from source to a val.

1. trait Foreach {
2.   trait Source {
3.     type I <: java.io.Closeable  // moved this line into Source
4.     def in : I
5.     def next(in : I) : Option[Int]
6.   }
7.   def source : Source
8.   
9.   def foreach[U](f : Int => U) : Unit = {
10.     // this assignment allows this example to compile
11.     val sameSource = source
12.     val s = sameSource.in
13.     try {
14.       def processNext : Unit = sameSource.next(s) match {
15.         case None => 
16.           ()
17.         case Some(value) => 
18.           f(value)
19.           processNext
20.       }
21.       
22.       processNext
23.     } finally {
24.       // correctly handle exceptions
25.       s.close
26.     }
27.   }
28. }

Companion Object Implicits

When a method requires an implicit there are several ways that the implicit is resolved. One way is to search for an implicit definition in the companion object of the required type. For example: def x(implicit m:MyClass) parameter m will search local scope, class hierarchy and the MyClass companion object for an implicit val or def. (More on implicit resolution later).

To demonstrate the method put the following code block into a file and run the script:

1. class X(val i:Int) {
2.   def add(implicit x:X)=println(x.i+i)
3. }
5. object X {
6.   implicit def xx = new X(3)
7. }
9. // implicit is obtained from companion object of X
10. new X(3).add
12. val other = new {
13.   def print(implicit x:X)=println(x.i)
14. }
16. // implicit is obtained from companion object of X
17. other.print
19. implicit def x = new X(32)
21. // implicit is obtained local scope
22. other.print

Running: scala impl.scala should produce:
6
3
32

Self Annotation vs inheritance

At first glance the "sself annotation" declaration seems similar to extending another class. (For a look at self annotations read the topic: Self Type.) They are completely different but the comparison is understandable since both of them provide access to the functionality of referenced class.

For example both of the following compile:

1. class Base {
2.   def magic = "bibbity bobbity boo!!"
3. }
5. trait Extender extends Base {
6.   def myMethod = "I can "+magic
7. }
9. trait SelfTyper {
10.   self : Base => 
11.   
12.   def myMethod = "I can "+magic
13. }

But the two are completely different. Extender can be mixed in with any class and adds both the "magic" and "myMethod" to the class it is mixed with. SelfType can only be mixed in with a class that extends Base and SelfTyper only adds the method "myMethod" NOT "magic".

Why is the "self annotations" useful? Because it allows several provides a way of declaring dependencies. One can think of the self annotation declaration as the phrase "I am useable with" or "I require a".

The following example demonstrates one possible reason to use self annotations instead of extend.

Note: These examples can be pasted into the REPL but I have shown that here because it would make the examples too long.

1. import java.io._
2. import java.util.{Properties => JProps}
4. trait Properties {
5.   def apply(key:String) : String
6. }
8. trait XmlProperties extends Properties {
9.   import scala.xml._
10.   
11.   def xml(key:String) = Elem(null,key,Null,TopScope, Text(apply(key)))
12. }
14. trait JSonProperties extends Properties {
15.   def json(key:String) : String = "%s : %s".format(key, apply(key))
16. }
18. trait StreamProperties {
19.   self : Properties => 
20.   
21.   protected def source : InputStream
22.   
23.   private val props = new JProps()
24.   props.load(source)
25.   
26.   def apply(key:String) = props.get(key).asInstanceOf[String]
27. }
29. trait MapProperties {
30.   self : Properties =>
31.   
32.   protected def source : Map[String,String]
33.   def apply(key:String) = source.apply(key)
34. }
36. val sampleMap = Map("1" -> "one", "2" -> "two", "3" -> "three")
37. val sampleData = """1=one
38.                     2=two
39.                     3=three"""
41. val sXml = new XmlProperties() with StreamProperties{
42.               def source = new ByteArrayInputStream(sampleData.getBytes)
43.            }
44. val mXml = new XmlProperties() with MapProperties{
45.               def source = sampleMap
46.            }
48. val sJSon = new JSonProperties() with StreamProperties{
49.               def source = new ByteArrayInputStream(sampleData.getBytes)
50.             }
51. val mJSon = new JSonProperties() with MapProperties{
52.               def source = sampleMap
53.             }
55. sXml.xml("1")
56. mXml.xml("2")
57. sJSon.json("1")
58. mJSon.json("2")

The justification for using self annotations here is flexibility. A couple other solutions would be

1. Use subclassing - this is poor solution because there would be an explosion of classes. Instead of having 5 traits you would need 7 traits. Properties, XmlProperties, JSonProperties, XmlStreamProperties, XmlMapProperties, JsonStreamProperties and JsonMapProperties. And if you later wanted to add a new type of properties or a new source like reading from a database then you need 2 new subclasses.
2. Composition - Another strategy is to use construct the XmlProperties with a strategy that reads from the source. This is essentially the same mechanism except that you need to build and maintain the the dependencies. It also makes layering more difficult. For example:
   
   1. trait IterableXmlProperties {                                            
   2.     self : MapProperties with XmlProperties => 
   3.     def xmlIterable = source.keySet map {xml _}
   4.   }
   5.   
   6.   new XmlProperties with MapProperties with IterableXmlProperties {def source = sampleMap}

The next question that comes to mind is why use extends then if self annotation is so flexible? My answer (and I welcome discussion on this point) has three points.

1. The first is of semantics and modeling. When designing a model it is often more logical to use inheritance because of the semantics that comes with inheriting from another object.
2. Another argument is pragmatism.
   Imagine the collections library where there is no inheritance. If you wanted a map with Iterable functionality you would have to always declare Traversable with Iterable with Map (and this is greatly simplified). That declaration would have to be used for virtually all methods that require both the Iterable and Map functionality. To say that is impractical is an understatement. Also the semantics of Map is changed from what it is now. The trait Map currently includes the concept of Iterable.
3. The last point is sealed traits/classes. When a trait is "sealed" all of its subclasses are declared within the same file and that makes the set of subclasses finite which allows certain compiler checks. This (as far as I know) cannot be done with self annotations.

Selection with Implicit Methods

This tip is a cool tip based on Daniel's Use Implicits to Select Types post. That post goes into more detail.

The idea is that depending on a given parameter of type T a particular type of object is required. There are several ways to do this. One would be to use matching to match the type T and create the correct object. Most likely the biggest draw back to matching is caused by type erasure. The following solution gets around that issue.

Two very interesting points.

1. Implicit methods do not require parameters. They can be selected based only on type parameters
2. Implicit methods are not subject to type erasure

1. // the base class we need
2. scala> abstract class X[T] { def id :Unit }
3. defined class X
5. /*
6. One of the types we need created.  It is the catch all case
7. */
8. scala> implicit def a[T] =new X[T] { def id =println("generic") }
9. a: [T]X[T]
11. /*
12. A specific subclass for integers
13. */
14. scala> implicit def b =new X[Int] { def id =println("Int") }
15. b: X[Int]
17. /*
18. One simple usage.  The most specific implicit will be used to 
19. create the object to be passed to g.  
20. */
21. scala> def f[T](a :T)(implicit g :X[T]) = g.id
22. f: [T](a: T)(implicit g: X[T])Unit
24. scala> f(5)
25. Int
27. scala> f('c')
28. generic
30. /*
31. This example demonstrates how erasure is not an issue because 
32. the selection of the implicit is done at compile time so 
33. the correct type is selected.  If a match was used instead 
34. then a more complicated solution would be required
35. */
36. scala> def g[T](l:List[T])(implicit i:X[T]) = i.id          
37. g: [T](l: List[T])(implicit i: X[T])Unit
39. scala> g(List(1,2,3))
40. Int
42. scala> g(List("a",2,3))
43. generic

Overcoming Type Erasure in Matching 2 (Variance)

A commenter (Brian Howard) on the post Overcoming Type Erasure in Matching 1 made a very good point:

Is there a way to deal with some type arguments being contravariant? Try the following:

class A

class B extends A

val AAFunction = new Def[Function1[A,A]]

((a:A) => a) match {case AAFunction(f) => Some(f(new A)); case _ => None} // this is OK

((a:A) => new B) match {case AAFunction(f) => Some(f(new A)); case _ => None} // this is OK

((b:B) => b) match {case AAFunction(f) => Some(f(new A)); case _ => None} // gives a ClassCastException, since new A is not a B

There is a way to do this, however the information is not captured in the Manifest. A manifest is not designed to do full reflection it is by design very light and has little impact on performance. So to provide the functionality requested by Brian one needs to add that information to the Extractor Definition. Have have a possible solution below.

1. scala> class A
2. defined class A
4. scala> class B extends A
5. defined class B
7. scala> object Variance extends Enumeration {
8.      |     val Co, Contra, No = Value
9.      | }
10. defined module Variance
12. scala> import Variance._
13. import Variance._
15. scala> class Def[C](variance:Variance.Value*)(implicit desired : Manifest[C]) {
16.      |     def unapply[X](c : X)(implicit m : Manifest[X]) : Option[C] = {
17.      |         val typeArgsTriplet = desired.typeArguments.zip(m.typeArguments).
18.      |                                                     zipWithIndex
19.      |         def sameArgs = typeArgsTriplet forall {
20.      |             case ((desired,actual),index) if(getVariance(index) == Contra) => 
21.      |                 desired <:< actual 
22.      |             case ((desired,actual),index) if(getVariance(index) == No) => 
23.      |                 desired == actual 
24.      |             case ((desired,actual),index) => 
25.      |                 desired >:> actual
26.      |         }
27.      |         
28.      |         val isAssignable = desired.erasure.isAssignableFrom(m.erasure) || (desired >:> m)
29.      |         if (isAssignable && sameArgs) Some(c.asInstanceOf[C])
30.      |         else None
31.      |     }
32.      |     def getVariance(i:Int) = if(variance.length > i) variance(i) else No
33.      | }
34. defined class Def
36. scala> val AAFunction = new Def[Function1[A,A]]
37. AAFunction: Def[(A) => A] = Def@64a65760
39. scala> ((a:A) => a) match {case AAFunction(f) => Some(f(new A)); case _ => None}
40. res0: Option[A] = Some(A@1bd4f279)
42. scala> ((a:A) => new B) match {case AAFunction(f) => Some(f(new A)); case _ => None}
43. res1: Option[A] = None
45. scala> ((b:B) => b) match {case AAFunction(f) => Some(f(new A)); case _ => None}
46. res2: Option[A] = None
48. scala> val BAFunction = new Def[Function1[B,A]](Contra,Co)
49. BAFunction: Def[(B) => A] = Def@26114629
51. scala> ((b:A) => b) match {case BAFunction(f) => Some(f(new B)); case _ => None}
52. res3: Option[A] = Some(B@15dcc3ca)

Overcoming Type Erasure in matching 1

Since Scala runs on the JVM (it also runs on .NET but we this tip is aimed at Scala on the JVM) much of the type information that is available at compile-time is lost during runtime. This means certain types of matching are not possible. For example it would be nice to be able to do the following:

1. scala> val x : List[Any] = List(1.0,2.0,3.0)
2. x: List[Any] = List(1, 2, 3)
4. scala> x match { case l : List[Boolean] => l(0) }

If you run this code the list matches the list of ints which is incorrect (I have ran the following with -unchecked so it will print the warning about erasure):

1. scala> val x : List[Any] = List(1.0,2.0,3.0)
2. x: List[Any] = List(1, 2, 3)
4. scala> x match { case l : List[Boolean] => l(0) }         
6. < console>:6: warning: non variable type-argument Boolean in type pattern List[Boolean] is unchecked since it is eliminated by erasure
7.        x match { case l : List[Boolean] => l(0) }
8.                           ^
9. java.lang.ClassCastException: java.lang.Double cannot be cast to java.lang.Boolean
10. at scala.runtime.BoxesRunTime.unboxToBoolean(Unknown Source)
11. at .< init>(< console>:6)

Another example is trying to match on structural types. Wouldn't it be nice to be able to do the following (We will solve this in a future post):

1. scala> "a string" match {
2.      | case l : {def length : Int} => l.length
3.      | }
4. < console>:6: warning: refinement AnyRef{def length: Int} in type pattern AnyRef{def length: Int} is unchecked since it is eliminated by erasure
5.        case l : {def length : Int} => l.length
6.                 ^
7. res5: Int = 8

So lets see what we can do about this. My proposed solution is to create an class that can be used as an extractor when instantiated to do the check.

This is a fairly advanced tip so make sure you have read up on Matchers and Manifests:

• Extractor 1
• Manifests
• Comparing Manifests

The key parts of the next examples are the Def class and the function 'func'. 'func' is defined in the comments in the code block.

The Def class is the definition of what we want to match. Once we have the definition we can use it as an Extractor to match List[Int] instances.

The Def solution is quite generic so it will satisfy may cases where you might want to do matching but erasure is getting in the way.

The secret is to use manifests:

• When the class is created the manifest for the class we want is captured.
• Each time a match is attempted the manifest of the class being matched is captured
• In the unapply method, the two manifests are compared and when they match we can return the matched element but cast to the desired type for the compiler

It is critical to notice the use of the typeArguments of the manifest. This returns a list of the manifests of each typeArgument. You cannot simply compare desired == m because manifest comparisons are not deep. There is a weakness in this code in that it only handles generics that are 1 level deep. For example:

List[Int] can be matched with the following code but List[List[Int]] will match anything that is List[List[_]]. Making the method more generic is an exercise left to the reader.

1. scala> import reflect._ 
2. import reflect._
4. /*
5. This is the key class
6. */
7. scala> class Def[C](implicit desired : Manifest[C]) {
8.      | def unapply[X](c : X)(implicit m : Manifest[X]) : Option[C] = {
9.      |   def sameArgs = desired.typeArguments.zip(m.typeArguments).forall {case (desired,actual) => desired >:> actual}
10.      |   if (desired >:> m && sameArgs) Some(c.asInstanceOf[C])
11.      |   else None
12.      | }
13.      | }
14. defined class Def
16. // first define what we want to match
17. scala> val IntList = new Def[List[Int]]
18. IntList: Def[List[Int]] = Def@6997f7f4
20. /*
21. Now use the object as an extractor.  the variable l will be a typesafe List[Int]
22. */
23. scala> List(1,2,3) match { case IntList(l) => l(1) : Int ; case _ => -1 }
24. res36: Int = 2
26. scala> List(1.0,2,3) match { case IntList(l) => l(1) : Int ; case _ => -1 }
27. res37: Int = -1
29. // 32 is not a list so it will fail to match
30. scala> 32 match { case IntList(l) => l(1) : Int ; case _ => -1 }
31. res2: Int = -1
33. scala> Map(1 -> 3) match { case IntList(l) => l(1) : Int ; case _ => -1 }
34. res3: Int = -1
36. /*
37. The Def class can be used with any Generic type it is not restricted to collections
38. */
39. scala> val IntIntFunction = new Def[Function1[Int,Int]]
40. IntIntFunction: Def[(Int) => Int] = Def@5675e2b4
42. // this will match because it is a function
43. scala> ((i:Int) => 10) match { case IntIntFunction(f) => f(3); case _ => -1}
44. res38: Int = 10
46. // no match because 32 is not a function
47. scala> 32 match { case IntIntFunction(f) => f(3); case _ => -1}
48. res39: Int = -1
50. // Cool Map is a function so it will match
51. scala> Map(3 -> 100) match { case IntIntFunction(f) => f(3); case _ => -1}
52. res6: Int = 100
54. /*
55. Now we see both the power and the limitations of this solution.
57. One might expect that:
58.    def func(a:Any) = {...} 
59. would work.  
61. However, if the function is defined with 'Any' the compiler does not pass in the required information so the manifest that will be created will be a Any manifest object.  Because of this the more convoluted method declaration must be used so the type information is passed in. 
63. I will discuss implicit parameters in some other post
64. */
65. scala> def func[A](a:A)(implicit m:Manifest[A]) = {
66.      |   a match {
67.      |     case IntList(l) => l.head                   
68.      |     case IntIntFunction(f) => f(32)             
69.      |     case i:Int => i                             
70.      |     case _ => -1                                
71.      |   } 
72.      | }
73. func: [A](a: A)(implicit m: Manifest[A])Int
75. scala> func(List(1,2,3))                           
76. res16: Int = 1
78. scala> func('i')                                   
79. res17: Int = -1
81. scala> func(4)
82. res18: Int = 4
84. scala> func((i:Int) => i+2)
85. res19: Int = 34
87. scala> func(Map(32 -> 2))
88. res20: Int = 2

Comparing Manifests

Manifests are Scala's solution to Java's type erasure. It is not a complete solution as of yet but it does have several useful applications. Manifests were originally added to Scala 2.7 in an extremely limited form but have been improved a great deal for Scala 2.8. Now more powerful comparisons of manifests are possible. For another introduction to Manifests (2.7 manifests) see Manifests.

This post looks at a few ways to create manifests as well as how to compare manifests. The goal is to create a method that can be used in testing to require that a certain exception is thrown during a code block:

1. scala> intercepts[Exception] {println("hi :)")}                                            
2. hi :)
3. Expected java.lang.Exception but instead no exception was raised

The code snippet above is a failure because println does not throw an exception. In addition to requiring manifests this code snippet also is a custom control structure, for more information on those see Control Structure Tag

But before writing the intercepts methods a short inspection of the new manifest comparison operators:

1. scala> import scala.reflect.{
2.      |   Manifest, ClassManifest
3.      | }
4. import scala.reflect.{Manifest, ClassManifest}
6. // from class creates a manifest object given a class object
7. scala> import ClassManifest.fromClass
8. import ClassManifest.fromClass
10. // several comparisons using <:<
11. scala> fromClass(classOf[Exception]) <:< fromClass(classOf[Exception])
12. res4: Boolean = true
14. scala> fromClass(classOf[Exception]) <:< fromClass(classOf[RuntimeException])
15. res5: Boolean = false
17. scala> fromClass(classOf[Exception]) <:< fromClass(classOf[AssertionError])         
18. res6: Boolean = false
20. // now the opposite operator >:>
21. scala> fromClass(classOf[Exception]) >:> fromClass(classOf[AssertionError])
22. res7: Boolean = false
24. scala> fromClass(classOf[Exception]) >:> fromClass(classOf[RuntimeException])
25. res8: Boolean = true
27. scala> fromClass(classOf[Exception]) >:> fromClass(classOf[Error])           
28. res9: Boolean = false
30. scala> fromClass(classOf[Exception]) >:> fromClass(classOf[Throwable])
31. res10: Boolean = false
33. // the method singleType creates a manifest given an object
34. scala> ClassManifest.singleType(new RuntimeException())
35. res12: scala.reflect.Manifest[Nothing] = java.lang.RuntimeException.type
37. scala> ClassManifest.singleType(new RuntimeException()) <:< fromClass(classOf[Throwable])
38. res13: Boolean = true
40. scala> fromClass(classOf[Exception]) <:< fromClass(classOf[Throwable])                   
41. res14: Boolean = true

Now the implementation of intercepts:

1. scala> import scala.reflect.{
2.      |   Manifest, ClassManifest
3.      | }
4. import scala.reflect.{Manifest, ClassManifest}
6. scala> 
8. scala> import ClassManifest.singleType
9. import ClassManifest.singleType
11. scala>  def intercepts[E <: Throwable](test : => Unit)(implicit m:Manifest[E]) : Unit = {
12.      |     import Predef.{println => fail}
13.      |     try {
14.      |       test
15.      |       // this is a failure because test is expected to throw an exception
16.      |       fail("Expected "+m.toString+" but instead no exception was raised")
17.      |     }catch{
18.      |       // this checks that the expected type (m) is a superclass of the class of e
19.      |       case e if (m >:> singleType(e)) => ()
20.      |       // any other error is handled here
21.      |       case e => fail("Expected "+m.toString+" but instead got "+e.getClass)
22.      |     }
23.      |   }
24. intercepts: [E <: Throwable](test: => Unit)(implicit m: scala.reflect.Manifest[E])Unit
26. scala> intercepts[Exception] {println("hi :)")}                                            
27. hi :)
28. Expected java.lang.Exception but instead no exception was raised
30. scala> intercepts[Exception] { throw new IllegalArgumentException("why not throw this :)")}
32. scala> intercepts[Exception] { throw new AssertionError("The method should complain")}     
33. Expected java.lang.Exception but instead got class java.lang.AssertionError

Type aliasing and implicit conversions in harmony

This topic combines advanced two topics. types and implicit methods. This topic is not really intended to be instructional as much as a illustration of the cool stuff you can do with the language. As always becareful not to cut yourself :-)

In keeping with the uniform principle of Scala, types can defined as variables. This is useful for several reasons but this topic covers a cool/fun effect of having types be declared like variables. Type Aliasing. In the example below an alias | is created for the Either class. This allows the | to be used in place of Either.

1. // Start of example 1.  creating the type alias
2. // define the | type
3. scala> type |[A,B] = Either[A,B]
4. defined type alias $bar
6. // If a Type has 2 parameters it can be used in operator form
7. scala> Array[Int | Long](Left(5),Right(12L))
8. res0: Array[|[Int,Long]] = Array(Left(5), Right(12))
10. // start of example 2.  Simplify creation of an Array (or other collection) of either
11. scala> implicit def makeLeft[A,B](a:A):Either[A,B] = Left(a)
12. makeLeft: [A,B](a: A)Either[A,B]
14. scala> implicit def makeRight[A,B](b:B):Either[A,B] = Right(b) 
15. makeRight: [A,B](b: B)Either[A,B]
17. // Since there are implicits to convert to Right and Left the values in the Array will be wrapped
18. // automatically.  Makes the syntax MUCH cleaner and easier to read.
19. scala> Array[Int|String](5,"Wurst",123,2,6)
20. res1: Array[|[Int,String]] = Array(Left(5), Right(Wurst), Left(123), Left(2), Left(6))

Extractors 3 (Operator Style Matching)

One of the blessings and curses of Scala the several rules for creating expressive code (curse because it can be used for evil.) One such rule is related to extractors that allows the following style of match pattern:

1. List(1,2,3) match {
2.   case 1 :: _ => println("found a list that starts with a 1")
3.   case _ => println("boo")
4. }

The rule is very simple. An extractor object that returns Option[Tuple2[_,_]] (or equivalently Option[(_,_)]) can be expressed in this form.

In other words: object X {def unapply(in:String):Option[(String,String)] = ...} can be used in a case statement like: case first X head => ... or case "a" X head => ....

Example to extract out the vowels from a string:

1. scala> object X { def unapply(in:String):Option[(RichString,RichString)] = Some(in.partition( "aeiou" contains _ )) }
2. defined module X
4. scala> "hello world" match { case head X tail => println(head, tail) }
5. (eoo,hll wrld)
7. // This is equivalent but a different way of expressing it
8. scala> "hello world" match { case X(head, tail) => println(head, tail) }       
9. (eoo,hll wrld)

Example for Matching the last element in a list. Thanks to 3-things-you-didnt-know-scala-pattern.html:

1. scala> object ::> {def unapply[A] (l: List[A]) = Some( (l.init, l.last) )}
2. defined module $colon$colon$greater
4. scala> List(1, 2, 3) match {
5.      | case _ ::> last => println(last)
6.      | }
7. 3
9. scala> (1 to 9).toList match {
10.      | case List(1, 2, 3, 4, 5, 6, 7, 8) ::> 9 => "woah!"
11.      | }
12. res12: java.lang.String = woah!
14. scala> (1 to 9).toList match {
15.      | case List(1, 2, 3, 4, 5, 6, 7) ::> 8 ::> 9 => "w00t!"
16.      | }
17. res13: java.lang.String = w00t!