New Scala 3 Syntax

If you have prior Scala experience, Scala 3 introduces a new optional braces syntax that makes it look a lot more like Python or Haskell, where Java-style curly braces ({…}) are replaced with indentation that becomes significant. The examples in the previous chapter and throughout the book use it.

This syntax has several benefits. It is more concise. For Python developers who decide to learn Scala, it will feel more familiar to them (and vice versa).

There is also a new syntax for control structures like for loops and if expressions. For example, if condition then … instead of the older if (condition) …. Also, for … do println(…) instead of for {…} println(…).

The disadvantage of these changes is that they are strictly not necessary. Some breaking changes in Scala 3 are necessary to move the language forward, but you could argue these syntax changes aren’t required. You also have to be careful to use tabs and spaces consistently for indentation.

The new constructs are the defaults supported by the compiler, but using the compiler flags -old-syntax and -noindent will enforce the old syntax constructs. Another flag, -new-syntax makes the new keywords then and do required. Finally, the compiler can now rewrite your code to use whichever style you prefer. Add the -rewrite compiler flag, for example -rewrite -new-syntax.

I opposed these changes initially, because they aren’t strictly necessary. However, now that I have worked with them, I believe the advantages outweigh the disadvantages. I also suspect that the syntax changes are the future for Scala and eventually the old syntax could be deprecated. We’ll see. Hence, I have chosen to use the new conventions throughout this edition of the book. I will mention other pros and cons of these changes as we explore examples.

OldVsNewSyntax provides examples of the old and new syntax.

Semicolons

Semicolons are expression delimiters and they are inferred. Scala treats the end of a line as the end of an expression, except when it can infer that the expression continues to the next line, even for the following example:

scala> val s = "hello"
     |  + "world"
     |  + "!"
val s: String = helloworld!

The Scala 2 REPL was more aggressive at interpreting the end of a line as the end of an expression, so the previous example would infer “hello” for the definition of s and then throw an error for the next two lines.

Conversely, you can put multiple expressions on the same line, separated by semicolons.

Variable Declarations

Scala allows you to decide whether a variable is immutable (read-only) or not (read-write) when you declare it. We’ve already seen that an immutable “variable” is declared with the keyword val:

val array: Array[String] = new Array(5)

Scala is like Java in that most variables are actually references to heap-allocated objects. Hence, the array reference cannot be changed to point to a different Array, but the array elements themselves are mutable, so the elements can be modified:

scala> val array: Array[String] = new Array(5)
val array: Array[String] = Array(null, null, null, null, null)

scala> array = new Array(2)
1 |array = new Array(2)
  |^^^^^^^^^^^^^^^^^^^^
  |Reassignment to val array

scala> array(0) = "Hello"

scala> array
val res1: Array[String] = Array(Hello, null, null, null, null)

A val must be initialized when it is declared, except in certain contexts like abstract fields in type declarations.

Similarly, a mutable variable is declared with the keyword var and it must also be initialized immediately (in most cases), even though it can be changed later:

scala> var stockPrice: Double = 100.0
var stockPrice: Double = 100.0

scala> stockPrice = 200.0
stockPrice: Double = 200.0

To be clear, we changed the value of stockPrice itself. However, the “object” that stockPrice refers to can’t be changed, because Doubles in Scala are immutable.

In Java, so-called primitive types, char, byte, short, int, long, float, double, and boolean, are fundamentally different than reference objects. Indeed, there is no object and no reference, just the “raw” value. Scala tries to be consistently object-oriented, so these types are actually objects with methods, like reference types (see ReferenceVsValueTypes). However, Scala compiles to primitives where possible, giving you the performance benefit they provide (see SpecializationForValueTypes for details).

Consider the following REPL session, where we define a Person class with immutable first and last names, but a mutable age (because people age, I guess). The parameters are declared with val and var, respectively, making them both fields in Person:

// src/script/scala/progscala3/typelessdomore/Human.scala
scala> class Human(val name: String, var age: Int)
// defined class Human

scala> val p = new Human("Dean Wampler", 29)
val p: Human = Human@165a128d

scala> p.name
val res0: String = Dean Wampler

scala> p.name = "Buck Trends"
1 |p.name = "Buck Trends"
  |^^^^^^^^^^^^^^
  |Reassignment to val name

scala> p.name
val res1: String = Dean Wampler

scala> p.age
val res2: Int = 29

scala> p.age = 30

scala> p.age
val res3: Int = 30

scala> p.age = 31; p.age  // Use semicolon to join two expressions...
val res4: Int = 31

Use immutable values whenever possible to eliminate a class of bugs caused by mutability. For example, a mutable object is dangerous as a key in hash-based maps. If the object is mutated, the output of the hashCode method will change, so the corresponding value won’t be found at the original location.

More common is unexpected behavior when an object you are using is being changed by another thread. Borrowing a phrase from Quantum Physics, these bugs are spooky action at a distance. Nothing you are doing locally accounts for the unexpected behavior; it’s coming from somewhere else.

These are the most pernicious bugs in multithreaded programs, where synchronized access to shared, mutable state is required, but difficult to get right. Using immutable values eliminates these issues.

Ranges

Sometimes we need a sequence of numbers from some start to finish. A Range literal is just what we need. The following examples show how to create ranges for the types that support them, Int, Long, Char, BigInt, which represents integers of arbitrary size, and BigDecimal, which represents floating-point numbers of arbitrary size. Float and Double were supported in Scala 2, but floating point arithmetic makes range calculations error prone. Hence, Scala 3 drops ranges for Float and Double.

You can create ranges with an inclusive or exclusive upper bound, and you can specify an interval not equal to one (some output elided to fit):

scala> 1 to 10                // Int range inclusive, interval of 1, (1 to 10)
val res0: scala.collection.immutable.Range.Inclusive = Range 0 to 10

scala> 1 until 10             // Int range exclusive, interval of 1, (1 to 9)
val res1: Range = Range 0 until 10

scala> 1 to 10 by 3           // Int range inclusive, every third.
val res2: Range = inexact Range 0 to 10 by 3

scala> 10 to 1 by -3          // Int range inclusive, every third, counting down.
val res3: Range = Range 10 to 1 by -3

scala> 1L to 10L by 3         // Long
val res4: ...immutable.NumericRange[Long] = NumericRange 1 to 10 by 3

scala> 'a' to 'g' by 3         // Char
val res5: ...immutable.NumericRange[Char] = NumericRange a to g by

scala> BigInt(1) to BigInt(10) by 3
val res6: ...immutable.NumericRange[BigInt] = NumericRange 1 to 10 by 3

scala> BigDecimal(1.1) to BigDecimal(10.3) by 3.1
val res7: ...immutable.NumericRange.Inclusive[BigDecimal] =
  NumericRange 1.1 to 10.3 by 3.1

Partial Functions

A PartialFunction[A,B] is a special kind of function with its own literal syntax. A is the type of the single parameter the function accepts and B is the return type.

The literal syntax for a PartialFunction consists only of case clauses, which we saw in ASampleApplication, that do pattern matching on the input to the function. There is no function parameter shown explicitly, but when each input is processed, it is passed to the body of the partial function.

For comparison, is a regular function that does pattern matching and similar partial function, adapted from the example we explored in ASampleApplication:

// src/script/scala/progscala3/typelessdomore/FunctionVsPartialFunction.scala
scala> import progscala3.introscala.shapes._

scala> val func: Message => String = message => message match
     |   case Exit => "Got Exit"
     |   case Draw(shape) => s"Got Draw($shape)"
     |   case Response(str) => s"Got Response($str)"

scala> val pfunc: PartialFunction[Message, String] =
     |   case Exit => "Got Exit"
     |   case Draw(shape) => s"Got Draw($shape)"
     |   case Response(str) => s"Got Response($str)"

scala> func(Draw(Circle(Point(0.0,0.0), 1.0)))
     | pfunc(Draw(Circle(Point(0.0,0.0), 1.0)))
     | func(Response(s"Say hello to pi: 3.14159"))
     | pfunc(Response(s"Say hello to pi: 3.14159"))
val res0: String = Got Draw(Circle(Point(0.0,0.0),1.0))
val res1: String = Got Draw(Circle(Point(0.0,0.0),1.0))
val res2: String = Got Response(Say hello to pi: 3.14159)
val res3: String = Got Response(Say hello to pi: 3.14159)

Function definitions can be a little harder to read than method definition. The function func is a named function of type Message => String. The equal sign starts the body, message => message match ....

The partial function, pfunc, is simpler. It’s type is PartialFunction[Message, String]. There is no argument list, just a set of case match clauses, which happen to be identical to the clauses in func.

The concept of a partial function is simpler than it might appear. In essence, a partial function will only handle certain inputs, so don’t send it something it doesn’t know how to handle. A classic example from mathematics is division, x/y, which is undefined when the denominator y is 0. Hence, division is a partial function.

If a partial function is called with an input that doesn’t match one of the case clauses, a MatchError is thrown at runtime. Both func and pfunc are actually total, because they handle all possible Message arguments. Try commenting out the case Exit clauses in both func and pfunc. You’ll get a a compiler warning for func, because it can determine that the match clauses don’t handle all possible inputs. It won’t complain about pfunc, because that situation is by design.

You can test if a PartialFunction will match an input using the isDefinedAt method. This function avoids the risk of throwing a MatchError exception.

You can also “chain” PartialFunctions together: pf1.orElse(pf2).orElse(pf3) …. If pf1 doesn’t match, then pf2 is tried, then pf3, etc. A MatchError is only thrown if none of them matches.

Let’s explore these points with the following example:

// src/script/scala/progscala3/typelessdomore/PartialFunctions.scala

val pfs: PartialFunction[Any,String] =                               
  case s:String => "YES"
val pfd: PartialFunction[Any,String] = {                             
  case d:Double => "YES"
}

val pfsd = pfs.orElse(pfd)                                           

A partial function that only matches on strings, using the braceless syntax.

A partial function that only matches on doubles, using braces.

Combine the two functions to construct a new partial function that matches on strings and doubles.

The next block of code in the script tries different values with the three partial functions to confirm expected behavior. Note that integers are not handled by any combination. A helper function tryPF is used to try the partial function and catch possible MatchError exceptions. So, a string is returned for both success and failure:

def tryPF(x: Any, f: PartialFunction[Any,String]): String =
  try f(x)
  catch case _: MatchError => "ERROR!"

assert(tryPF("str", pfs)  == "YES")
assert(tryPF("str", pfd)  == "ERROR!")
assert(tryPF("str", pfsd) == "YES")
assert(tryPF(3.142, pfs)  == "ERROR!")
assert(tryPF(3.142, pfd)  == "YES")
assert(tryPF(3.142, pfsd) == "YES")
assert(tryPF(2, pfs)      == "ERROR!")
assert(tryPF(2, pfd)      == "ERROR!")
assert(tryPF(2, pfsd)     == "ERROR!")

assert(pfs.isDefinedAt("str")  == true)
assert(pfd.isDefinedAt("str")  == false)
assert(pfsd.isDefinedAt("str") == true)
assert(pfs.isDefinedAt(3.142)  == false)
assert(pfd.isDefinedAt(3.142)  == true)
assert(pfsd.isDefinedAt(3.142) == true)
assert(pfs.isDefinedAt(2)      == false)
assert(pfd.isDefinedAt(2)      == false)
assert(pfsd.isDefinedAt(2)     == false)

Finally, we can lift a partial function into a regular (“total”) function that returns an option, Some(value), when the partial function is defined for the input argument and None when it isn’t. We can also unlift a single-parameter function. Here is a session that uses pfs:

scala> val fs = pfs.lift
val fs: Any => Option[String] = <function1>

scala> fs("str")
val res0: Option[String] = Some(YES)

scala> fs(3.142)
val res1: Option[String] = None

scala> val pfs2 = fs.unlift
val pfs2: PartialFunction[Any, String] = <function1>

scala> pfs2("str")
val res3: String = YES

scala> tryPF(3.142, pfs2)  // Use tryPF we defined above
val res4: String = ERROR!

Infix Operator Notation

In the previous example, we combined two partial functions using orElse. This can be written equivalently in two ways:

val pfsd1 = pfs.orElse(pfd)
val pfsd2 = pfs orElse pfd

When a method takes a single parameter, you can drop the period after the object and drop the parentheses around the supplied argument. In this case, pfs orElse pfd has a cleaner appearance than pfs.orElse(pfd), which is why this syntax is popular. This notation is called infix notation, because orElse is between the object and argument. This syntax is also called operator notation, because it is especially popular when writing libraries where algebraic notation is convenient. For example, you can write your own libraries for matrices and define a method named * for matrix multiplication using the * “operator”. Then you can write expressions like val matrix3 = matrix1 * matrix2.

Method Declarations

Let’s explore method definitions, using a modified version of our Shapes hierarchy from before.

// src/main/scala/progscala3/typelessdomore/shapes/Shapes.scala
package progscala3.typelessdomore.shapes

case class Point(x: Double = 0.0, y: Double = 0.0):                  
  def shift(deltax: Double = 0.0, deltay: Double = 0.0) =            
    copy(x + deltax, y + deltay)

scala> val p1 = new Point(x = 3.3, y = 4.4)    // Used named arguments explicitly.
val p1: Point = Point(3.3,4.4)

scala> val p2 = p1.copy(y = 6.6)  // Copied with a new y value.
val p2: Point = Point(3.3,6.6)

abstract class Shape():
  def draw(offset: Point = Point(0.0, 0.0))(f: String => Unit): Unit =
    f(s"draw($offset, ${this})")

val s = Circle(Point(0.0, 0.0), 1.0)
s.draw(Point(1.0, 2.0))(str => println(str))

s.draw(Point(1.0, 2.0)){str => println(str)}

s.draw(Point(1.0, 2.0)) { str =>
  println(str)
}

s.draw(Point(1.0, 2.0)) {
  str => println(str)
}

scala> s.draw(Point(1.0, 2.0)):
     |   str => println(str)
2 |  str => println(str)
  |      ^
  |      parentheses are required around the parameter of a lambda
  |      This construct can be rewritten automatically under -rewrite.
1 |s.draw(Point(1.0, 2.0)):
  |^
  |not a legal formal parameter
2 |  str => println(str)

s.draw() {
  str => println(str)
}

s.draw(Point(1.0, 2.0), str => println(str))

s.draw(Point(1.0, 2.0))(str => println(str))
s.draw(Point(1.0, 2.0))(println)

// src/script/scala/progscala3/typelessdomore/Futures.scala
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global            
import scala.util.{Failure, Success}

def sleep(millis: Long) = Thread.sleep(millis)                       

(1 to 5) foreach { i =>
  val future = Future {                                              
    val duration = (math.random * 1000).toLong
    sleep(duration)
    if i == 3 then throw new RuntimeException(s"$i -> $duration")
    duration
  }
  future onComplete {                                                
    case Success(result)    => println(s"Success! #$i -> $result")
    case Failure(throwable) => println(s"FAILURE! #$i -> $throwable")
  }
}
sleep(1000)  // Wait long enough for the "work" to finish.
println("Finished!")

Success! #2 -> 178
Success! #1 -> 207
FAILURE! #3 -> java.lang.RuntimeException: 3 -> 617
Success! #5 -> 738
Success! #4 -> 938
Finished!

apply[T](body: => T)(/* explained below */): Future[T]

import scala.concurrent.ExecutionContext.Implicits.global

apply[T](body: => T)(using executor: ExecutionContext): Future[T]

Future(work)(using someExecutionContext)

given myEC as MyCustomExecutionContext(arguments)
...
val future = Future(work)

abstract def onComplete[U](
  f: (Try[T]) => U)(using executor: ExecutionContext): Unit

// src/script/scala/progscala3/typelessdomore/Factorial.scala

def factorial(i: Int): Long =
  def fact(i: Int, accumulator: Long): Long =
    if (i <= 1) accumulator
    else fact(i - 1, i * accumulator)

  fact(i, 1L)

(0 to 5).foreach(i => println(s"$i: ${factorial(i)}"))

0: 1
1: 1
2: 2
3: 6
4: 24
5: 120

// src/script/scala/progscala3/typelessdomore/FactorialTailrec.scala
import scala.annotation.tailrec

def factorial(i: Int): Long =
  @tailrec
  def fact(i: Int, accumulator: Long): Long =
    if i <= 1 then accumulator
    else fact(i - 1, i * accumulator)

  fact(i, 1)

(0 to 5).foreach(i => println(s"$i: ${factorial(i)}"))

// src/script/scala/progscala3/typelessdomore/FibonacciTailrec.scala
scala> import scala.annotation.tailrec

scala> @tailrec
     | def fibonacci(i: Int): Long =
     |   if (i <= 1) 1L
     |   else fibonacci(i - 2) + fibonacci(i - 1)
4 |  else fibonacci(i - 2) + fibonacci(i - 1)
  |                          ^^^^^^^^^^^^^^^^
  |                 Cannot rewrite recursive call: it is not in tail position
4 |  else fibonacci(i - 2) + fibonacci(i - 1)
  |       ^^^^^^^^^^^^^^^^
  |       Cannot rewrite recursive call: it is not in tail position

// src/script/scala/progscala3/typelessdomore/CountTo.scala
import scala.annotation.tailrec

def countTo(n: Int): Unit =
  @tailrec
  def count(i: Int): Unit =
    if (i <= n) then
      println(i)
      count(i + 1)
  count(1)

countTo(5)

Inferring Type Information

Statically typed languages provide wonderful compile-time safety, but they can be very verbose if all the type information has to be explicitly provided. Scala’s type inference removes most of this explicit detail, but where it is still required, it can provide an additional benefit of documentation for the reader.

Some functional programming languages, like Haskell, can infer almost all types, because they do global type inference. Scala can’t do this, in part because Scala has to support subtype polymorphism, for object-oriented inheritance, which makes type inference harder.

We’ve already seen examples of Scala’s type inference. Here are two more examples, showing different ways to declare a Map:

scala> val map1: Map[Int, String] = Map.empty
val map1: Map[Int, String] = Map()

scala> val map2 = Map.empty[Int, String]
val map1: Map[Int, String] = Map()

The second form is more idiomatic most of the time. However, Map is actually a trait with concrete subclasses, so you’ll sometimes make declarations like this one for a TreeMap:

scala> import scala.collection.immutable.TreeMap
scala> val map3: Map[Int, String] = TreeMap.empty
val map3: Map[Int, String] = Map()

Here is a summary of the rules for when explicit type annotations are required in Scala.

The last case is somewhat rare, fortunately.

We’ll explore Scala’s types in ScalaTypeHierarchy.

Let’s look at a few examples of cases we haven’t seen yet where explicit types are required. First, look at overloaded methods:

// src/script/scala/progscala3/typelessdomore/MethodOverloadedReturn.scala

case class Money(value: Double)
case object Money {
  def apply(s: String): Money     = apply(s.toDouble)
  def apply(d: BigDecimal): Money = apply(d.toDouble)
}

While the Money constructor expects a Double, we want the user to have the convenience of passing a String or a BigDecimal (ignoring possible errors). So, we add two more apply methods to the companion object. Both call the apply(d: Double) method the compiler automatically generates for the companion object, corresponding to the primary constructor Money(value: Double).

The two methods have explicit return types. If you try removing them, you’ll get a compiler error:

scala> case class Money(value: Double)
     | case object Money {
     |  def apply(s: String)     = apply(s.toDouble)  // no return type
     |  def apply(d: BigDecimal) = apply(d.toDouble)  // no return type
     | }
4 | def apply(d: BigDecimal) = apply(d.toDouble)
  |                            ^
  |                    Overloaded or recursive method apply needs return type
3 | def apply(s: String)     = apply(s.toDouble)
  |                            ^
  |                    Overloaded or recursive method apply needs return type

Variadic Argument Lists

Scala supports methods that take variable argument lists (sometimes just called variadic methods). Consider this contrived example that computes the mean of Doubless:

// src/script/scala/progscala3/typelessdomore/VariadicArguments.scala

scala> object Mean1 {
     |   def calc1(ds: Double*): Double = calc2(ds :_*)
     |   def calc2(ds: Seq[Double]): Double = ds.sum/ds.size
     | }

scala> Mean1.calc1(1.0, 2.0)
val res0: Double = 1.5

scala> Mean1.calc2(Seq(1.0, 2.0))
val res1: Double = 1.5

The syntax ds: Double* means zero or more Doubles, a variable argument list. Since calc1 calls calc2, which expects a Seq[Double] argument. the unusual syntax (ds :_*) is how you take the variable argument list and convert to a sequence when needed.

Why have both functions? The examples show that both can be convenient for the user. In particular, using calc1 doesn’t require you to wrap values in a Seq first.

There are downsides. The API “footprint” is larger with two methods instead of one and the maintenance burden is larger.

Assuming you want both methods, why not use the same name, in particular, apply?

scala> object Mean2 {
     |   def apply(ds: Double*): Double = apply(ds :_*)
     |   def apply(ds: Seq[Double]): Double = ds.sum/ds.size
     | }
3 |  def apply(ds: Seq[Double]): Double = ds.sum/ds.size
  |      ^
  |      Double definition:
  |      def apply(ds: Double*): Double in object Mean2 at line 2 and
  |      def apply(ds: Seq[Double]): Double in object Mean2 at line 3
  |      have the same type after erasure.

In fact, ds: Double*$$ is converted to a kind of sequence internally, so effectively the methods look identical at the byte code level.

There’s a common idiom to break the ambiguity, add a first Double parameter in the first apply, then use a variable list for the rest of the supplied arguments:

scala> object Mean {
     |   def apply(d: Double, ds: Double*): Double = apply(d +: ds)
     |   def apply(ds: Seq[Double]): Double = ds.sum/ds.size
     | }
// defined object Mean

scala> Mean(1.0,2.0)
val res10: Double = 1.5

scala> Mean(Seq(1.0,2.0))
val res11: Double = 1.5

scala> Mean()
1 |Mean()
  |^^^^
  |None of the overloaded alternatives of method apply in object Mean with types
  | (ds: Seq[Double]): Double
  | (d: Double, ds: Double*): Double
  |match arguments ()

scala> Mean(Nil)
val res12: Double = NaN

When calling the second apply, the first one constructs a new sequence prepending d to ds using d +: ds. We’ll explain this syntax in MatchingOnSequences.

Finally, Nil is an object representing an empty sequence with any type of elements.

Reserved Words

Scala reserves some words for defining constructs like conditionals, declaring variables, etc. Some of the reserved words are marked with (soft), which means they can be used as regular identifiers for method and variable names, for example, but they are treated as keywords when used in particular contexts. All of the soft words are new reserved words in Scala 3. The reason for treating them as soft is to avoid breaking older code that happens to use them as identifiers.

reserved-words-table lists the reserved keywords in Scala. Many are found in Java and they usually have the same meanings in both languages.

Some Java methods use names that are reserved words by Scala, for example, java.util.Scan⁠ner.match. To avoid a compilation error, surround the name with single back quotes (“back ticks”), e.g., java.util.Scanner.`match`.

Literal Values

We’ve seen a few literal values already, such as val book = "Programming Scala", where we initialized a val book with a String literal, and (s: String) => s.toUpperCase, an example of a function literal. Let’s discuss all the literals supported by Scala.

val i: Int = 123                       // decimal
val x: Long = 0x123L                   // hexadecimal (291 decimal)
val f: Float = 123_456.789F            // 123456.789
val d: Double = 123_456_789.0123       // 123456789.0123
val y: BigInt = 0x123_a4b_c5d_e6f_789  // 82090347159025545
val z: BigDecimal = 123_456_789.0123   // 123456789.0123

0.14
3.14
3.14f
3.14F
3.14d
3.14D
3e5
3E5
3.14e+5
3.14e-5
3.14e-5f
3.14e-5F
3.14e-5d
3.14e-5D

scala> val b1 = true
b1: Boolean = true

scala> val b2 = false
b2: Boolean = false

'A'
'u0041'  // 'A' in Unicode
'
'
'012'    // '
' in octal
'	'

"Programming
Scala"
"He exclaimed, "Scala is great!""
"First	Second"

"""Programming
Scala"""
"""He exclaimed, "Scala is great!" """
"""First line

Second line	

Fourth line"""

// src/script/scala/progscala3/typelessdomore/MultilineStrings.scala

def hello(name: String) = s"""Welcome!
  Hello, $name!
  * (Gratuitous Star!!)
  |We're glad you're here.
  |  Have some extra whitespace.""".stripMargin

val hi = hello("Programming Scala")

val hi: String = Welcome!
  Hello, Programming Scala!
  * (Gratuitous Star!!)
We're glad you're here.
  Have some extra whitespace.

scala> "<hello> <world>".stripPrefix("<").stripSuffix(">")
val res0: String = hello> <world

scala> val sym1 = 'name             // Scala 2 only; single "tick"
scala> val sym2 = Symbol("name")    // Scala 2 and 3

val f1: (Int,String) => String       = (i, s) => s+i
val f2: Function2[Int,String,String] = (i, s) => s+i

// src/script/scala/progscala3/typelessdomore/TupleExample.scala

scala> val tup = ("Hello", 1, 2.3)               
val tup: (String, Int, Double) = (Hello,1,2.3)

scala> val tup2: (String, Int, Double) = ("World", 4, 5.6)
val tup2: (String, Int, Double) = (World,4,5.6)

scala> tup._1                                    
val res0: String = Hello

scala> tup._2
val res1: Int = 1

scala> tup._3
val res2: Double = 2.3

scala> val (s, i, d) = tup                       
val s: String = Hello
val i: Int = 1
val d: Double = 2.3

scala> println(s"s = $s, i = $i, d = $d")
s = Hello, i = 1, d = 2.3

scala> (1, "one")
val res3: (Int, String) = (1,one)

scala> 1 -> "one"
val res4: (Int, String) = (1,one)

scala> Tuple2(1, "one")           // Rarely used.
val res5: (Int, String) = (1,one)

// src/script/scala/progscala3/typelessdomore/StateCapitalsSubset.scala

scala> val stateCapitals = Map(
     |   "Alabama" -> "Montgomery",
     |   "Alaska"  -> "Juneau",
     |   // ...
     |   "Wyoming" -> "Cheyenne")
val stateCapitals: Map[String, String] =
  Map(Alabama -> Montgomery, Alaska -> Juneau, Wyoming -> Cheyenne)

Option, Some, and None: Avoiding nulls

Let’s discuss three useful types that express a very useful concept, when we may or may not have a value.

Most languages have a special keyword or type instance that’s assigned to reference variables when there’s nothing else for them to refer to. In Scala and Java, it’s called null.

Using null is a giant source of nasty bugs. What null really signals is that we don’t have a value in a given situation. If the value is not null, we do have a value. Why not express this situation explicitly with the type system and exploit type checking to avoid NullPointerExceptions?

Option lets us express this situation explicitly without using null. Option is an abstract class and its two concrete subclasses are Some, for when we have a value, and None, when we don’t.

You can see Option, Some, and None in action using the map of state capitals in the United States that we declared in the previous section:

scala> stateCapitals.get("Alabama")
     | stateCapitals.get("Wyoming")
     | stateCapitals.get("Unknown")
val res6: Option[String] = Some(Montgomery)
val res7: Option[String] = Some(Cheyenne)
val res8: Option[String] = None

scala> stateCapitals.getOrElse("Alabama", "Oops1")
     | stateCapitals.getOrElse("Wyoming", "Oops2")
     | stateCapitals.getOrElse("Unknown", "Oops3")
val res9: String = Montgomery
val res10: String = Cheyenne
val res11: String = Oops3

Map.get returns an Option[T], where T is String in this case. Either a Some wrapping the value is returned or a None when no value for the specified key was found.

In contrast, similar methods in other languages just return a T value, when found, or null.

By returning an Option, we can’t “forget” that we have to verify that something was returned. In other words, the fact that a value may not exist for a given key is enshrined in the return type for the method declaration. This also provides clear documentation for the user of Map.get about what can be returned.

The second group uses Map.getOrElse. This method returns either the value found for the key or it returns the second argument passed in, which functions as the default value to return.

So, getOrElse is more convenient, as you don’t need to process the Option, if a suitable default value exists.

To reiterate, because the Map.get method returns an Option, it automatically documents for the reader that there may not be an item matching the specified key. The map handles this situation by returning a None.

Also, thanks to Scala’s static typing, you can’t make the mistake of “forgetting” that an Option is returned and attempting to call a method supported by the type of the value inside the Option. You must extract the value first or handle the None case. Without an option return type, when a method just returns a value, it’s easy to forget to check for null before calling methods on the returned object.

// src/script/scala/progscala3/typelessdomore/Null.scala

import java.util.{HashMap => JHashMap}                     

val jhm = new JHashMap[String,String]()
jhm.put("one", "1")

val one1: String = jhm.get("one")                          
val one2: String | Null = jhm.get("one")                   

val two1: String = jhm.get("two")                          
val two2: String | Null = jhm.get("two")

$ scala -Yexplicit-nulls
...
scala> val one1: String = jhm.get("one")
1 |val one1: String = jhm.get("one")
  |                   ^^^^^^^^^^^^^^
  |                   Found:    String | UncheckedNull
  |                   Required: String

...

Sealed Class Hierarchies and Enumerations

While we’re discussing Option, let’s discuss a useful design feature it uses. A key point about Option is that there are really only two valid subtypes. Either we have a value, the Some case, or we don’t, the None case. There are no other subtypes of Option that would be valid. So, we would really like to prevent users from creating their own.

Scala 2 and 3 have a keyword sealed for this purpose. Option could be declared as follows:

sealed abstract class Option[+A] {...}
final case class Some[+A](a: A) extends Option[A] {...}
final case object None extends Option[Nothing] {...}

The sealed keyword tells the compiler that all subclasses must be declared in the same source file. Some and None are declared in the same file with Option in the Scala library. This technique effectively prevents additional subtypes of Option.

None has an interesting declaration. It is a case class with only one instance, so it is declared case object. The Nothing type along with the Null type are subtypes of all other types in Scala. We’ll explain Nothing in more detail in SeqsInFunctionalProgramming, if you get what I mean…

You can also declare a type final if you want to prevent users from subtyping it. If you want to encourage subtyping of a concrete class, you can declare it open. (This is redundant for abstract types.)

This same constraint on subclassing can now be achieved more concise in Scala 3 with the new enum syntax:

enum Option[+A] {
  case Some(a: A) {...}
  case None {...}
  ...
}

Organizing Code in Files and Namespaces

Scala adopts the package concept that Java uses for namespaces, but Scala offers more flexibility. Filenames don’t have to match the type names and the package structure does not have to match the directory structure. So, you can define packages in files independent of their “physical” location.

The following example defines a class MyClass in a package com.example.mypkg using the conventional Java syntax:

// src/main/scala/progscala3/typelessdomore/PackageExample1.scala
package com.example.mypkg

class MyClass:
  def mymethod(s: String): String = s

Scala also supports a block-structured syntax for declaring package scope:

// src/main/scala/progscala3/typelessdomore/PackageExample2.scala
package com:
  package example:
    package pkg1:
      class Class11:
        def m = "m11"

      class Class12:
        def m = "m12"

    package pkg2:
      class Class21:
        def m = "m21"
        def makeClass11 = new pkg1.Class11

        def makeClass12 = new pkg1.Class12

    package pkg3.pkg31.pkg311:
      class Class311:
        def m = "m21"

Two packages, pkg1 and pkg2, are defined under the com.example package. A total of three classes are defined between the two packages. The makeClass11 and makeClass12 methods in Class21 illustrate how to reference a type in the “sibling” package, pkg1. You can also reference these classes by their full paths, com.example.pkg1.Class11 and com.example.pkg1.Class12, respectively.

The package pkg3.pkg31.pkg311 shows that you can “chain” several packages together in one statement. It is not necessary to use a separate package statement for each package.

If you have package-level declarations, like types, in each of several parent packages that you want to bring into scope, use separate package statements as shown for each level of the package hierarchy with these declarations. Each subsequent package statement is interpreted as a subpackage of the previously specified package, as if we used the block-structure syntax shown previously. The first statement is interpreted as an absolete path.

Following the convention used by Java, the root package for Scala’s library classes is named scala.

Although the package declaration syntax is flexible, one limitation is that packages cannot be defined within classes and objects, which wouldn’t make much sense anyway.

Importing Types and Their Members

To use declarations in packages, you have to import them. However, Scala offers flexible options how items are imported:

import java.awt._                 
import java.io.File               
import java.io.File._             
import java.util.{Map, HashMap}   

Import everything in a package, using underscore ( _ ) as a wildcard.

Import an individual type.

Import all static member fields and methods in File.

Selectively import two types from java.util.

Java uses the asterisk character (*) as the wildcard for imports. In Scala, this character is allowed as a method name (e.g., for multiplication), so _ is used instead to avoid ambiguity.

The third line imports all the static methods and fields in java.io.File. The equivalent Java import statement would be import static java.io.File.*;. Scala doesn’t have an import static construct because it treats object types uniformly like other types.

You can put import statements almost anywhere, so you can scope their visibility to just where they are needed, you can rename types as you import them, and you can suppress the visibility of unwanted types:

def stuffWithBigInteger() = {

  import java.math.BigInteger.{
    ONE => _,                     
    TEN,                          
    ZERO => JAVAZERO }            

  // println( "ONE: "+ONE )     // ONE is effectively undefined
  println( "TEN: "+TEN )
  println( "ZERO: "+JAVAZERO )
}

Alias to _ to make it invisible. Use this technique when you want to import everything except a few items.

Import TEN from BigDecimal. It can be referenced simply as TEN.

Import ZERO but give it an alias. Use this technique to avoid shadowing other items with the same name. This is used a lot when mixing Java and Scala types, such as Java’s List and Scala’s List.

Because this import statement is inside stuffWithBigInteger, the imported items are not visible outside the function.

Finally, Scala 3 adds new ways to control how implicit definitions are imported. We’ll discuss these details in GivensAndImports, once we understand the new syntax and behaviors for given instances.

import progscala3.typelessdomore.api._

// src/main/scala/progscala3/typelessdomore/PackageObjects.scala
package progscala3.typelessdomore.api

val DEFAULT_COUNT = 5
def countTo(limit: Int = DEFAULT_COUNT) = (0 to limit).foreach(println)

class Class1:
  def m = "cm1"

object Object1:
  def m = "om1"

// src/main/scala-2/progscala3/typelessdomore/PackageObjects.scala
package progscala3.typelessdomore   // Notice, no ".api"

package object api {
	val DEFAULT_COUNT = 5
	def countTo(limit: Int = DEFAULT_COUNT) = (0 to limit).foreach(println)

	class Class1 {
	  def m = "cm1"
	}

	object Object1 {
	  def m = "om1"
	}
}

Abstract Types Versus Parameterized Types

We mentioned in ATasteOfScala that Scala supports parameterized types, which are very similar to generics in Java. (The terms are somewhat interchangeable, but the Scala community uses parameterized types.) Java uses angle brackets (<…>), while Scala uses square brackets ([…]), because < and > are often used for method names.

Because we can plug in almost any type for a type parameter A in a collection like List[A], this feature is called parametric polymorphism, because generic implementations of the List methods can be used with instances of any type A.

Consider the declaration of Map, which is written as follows, where K is the keys type and V is the values type.

trait Map[K, +V] extends Iterable[(K, V)] with ...

The + in front of the V means that Map[K, V2] is a subtype of Map[K, V1] for any V2 that is a _subtype of V1. This is called covariant typing. It is a reasonably intuitive idea. If we have a function f(map: Map[String, Any]), it makes sense that passing a Map[String, Double] to it should work fine, because the function has to assume values of Any, a parent type of Double.

In contrast, the key K is invariant. We can’t pass Map[Any, Any] to f nor any Map[S, Any] for some subtype or supertype S of String.

If there is a – in front of a type parameter, the relationship goes the other way; Foo[B] would be a supertype of Foo[A], if B is a subtype of A and the declaration is Foo[-A] (called contravariant typing). This is less intuitive, but also not as important to understand now. We’ll see how it is important for function types in ParameterizedTypes.

Scala supports another type abstraction mechanism called abstract types, which can be applied to many of the same design problems for which parameterized types are used. However, while the two mechanisms overlap, they are not redundant. Each has strengths and weaknesses for certain design problems.

These types are declared as members of other types, just like methods and fields. Here is an example that uses an abstract type in a parent class, then makes the type member concrete in child classes:

// src/main/scala/progscala3/typelessdomore/AbstractTypes.scala
package progscala3.typelessdomore
import scala.io.Source

abstract class BulkReader:
  type In                                                            
  val source: In
  /** Read source and return a sequence of Strings */
  def read: Seq[String]

case class StringBulkReader(source: String) extends BulkReader:      
  type In = String
  def read: Seq[String] = Seq(source)

case class FileBulkReader(source: Source) extends BulkReader:        
  type In = Source
  def read: Seq[String] = source.getLines.toVector

Abstract type, really just like any abstract field or method.

Concrete subtype of BulkReader where In is defined to be String. Note that the type of the source parameter must match.

Concrete subtype of BulkReader where In is defined to be Source, the Scala library class for reading sources, like files. Source.getLines returns an iterator, which we can easy read into a Vector with toVector.

Strictly speaking, we don’t need to declare the source field in the parent class, but I put it there to show you that the concrete case classes can make it a constructor parameter, where the specific type is specified.

Using these readers:

scala> import progscala3.typelessdomore.{StringBulkReader, FileBulkReader}

scala> new StringBulkReader("Hello Scala!").read
val res1: Seq[String] = List(Hello Scala!)

scala> val lines = FileBulkReader(Source.fromFile("README.md")).read
val lines: Seq[String] = Vector(# Programming Scala, 3rd Edition, ...)

scala> lines(0)    // look at two lines...
     | lines(2)
val res2: String = # Programming Scala, 3rd Edition
val res3: String = ## README for the Code Examples

The type field is used like a type parameter in a parameterized type. In fact, as an exercise, try rewriting the example to use type parameters, e.g., BulkReader[In].

So what’s the advantage here of using type members instead of parameterized types? The latter are best for the case where the type parameter has no relationship with the parameterized type, like List[A] when A is Int, String, Person, etc. A type member works best when it “evolves” in parallel with the enclosing type, as in our BulkReader example, where the type member needed to match the “behaviors” expressed by the enclosing type, specifically the read method. Sometimes this characteristic is called family polymorphism or covariant specialization.

For completeness, another use for type members is to provide a convenient alias for a more complicated type. For example, suppose you use (String, Double) tuples a lot in some code. You could either declare a class for it or use a type alias for a simple alternative:

scala> object Foo:
     |   type Record = (String, Double)
     |   def transform(record: Record): Record =
     |     (record._1.toUpperCase, 2*record._2)
// defined object Foo

scala> Foo.transform("hello", 10)
val res0: Foo.Record = (HELLO,20.0)

Notice the type shown for res0. In fact, concrete type members are always type aliases.

Recap and What’s Next

We covered a lot of practical ground, such as literals, keywords, file organization, and imports. We learned how to declare variables, methods, and classes. We learned about Option as a better tool than null, plus other useful techniques. In the next chapter, we will finish our fast tour of the Scala “basics” before we dive into more detailed explanations of Scala’s features.