Higher-Order Functions

ASIDE ON SCOPING

After a variable is introduced in a program, the variable’s name is bound to that variable’s value. The part of the program where this binding exists is called the scope of the declaration. Scoping rules vary from programming language to programming language. The state of affairs is somewhat simpler than it used to be because almost all languages rely on static (or lexical) scoping. Only a few languages continue to offer a form of dynamic (or late binding) scoping. However, many popular languages implement their static scoping rules differently, so caution is still warranted.

The following Scala program involves multiple scopes:

Scala

var str: String = ""

def f(x: Int): Int =
   if x > 0 then
      val str: Int = x - 1
      str + 1
   else
      val x: String = str.toUpperCase
      x.length

The outermost scope defines a variable str, of type String. The body of function f creates its own scope, in which a variable x, of type Int, is defined (the argument to the function). The block of code that constitutes the then part of the conditional has its own scope in which a new variable str, of type Int, is declared. Similarly, the else block defines a new variable x, of type String, in its own scope. Variables do not exist outside their scopes: Outside function f, variable str is the string defined on the first line, and there is no variable named x.

The variables str and x declared in the inner scopes shadow the variables with the same names from the outer scopes. Java forbids such shadowing and forces you to pick different names for the variables declared inside the then and else blocks.

While it is often the case that every block of code defines its own scope, not all languages adhere to this rule. JavaScript and Python, for instance, introduce a new scope for the body of a function, but not for the then and else branches of a conditional, or the body of a loop. This can be confusing when you are used to the more mainstream scoping rules. As an illustration, consider the following Python program:

Python

x = 1

def f():
    x = 2
    if x > 0:
       x = 3
       y = 4
    print(x)  # prints 3
    print(y)  # prints 4

f()
print(x)  # prints 1
print(y)  # error: name 'y' is not defined

The body of function f defines its own scope, but the block of code inside if does not. Instead, x=3 is an assignment to the variable x declared in the scope of the function (initialized with 2), and y=4 introduces a variable y inside that same scope. In particular, this variable y continues to exist after the if statement and has value 4. The print(x) statement inside function f prints the value of the variable x in the scope of the function, which is 3, while the print(x) statement outside function f prints the value of the variable x in the outermost scope, which is 1. The final print(y) statement triggers an error, since no y variable has been declared outside the scope of the function. The behavior would be the same in JavaScript. Contrast this with Scala:

Scala

var x = 1

def f() =
   var x = 2
   if x > 0 then
       var x = 3
       var y = 4
   println(x) // prints 2
   println(y) // rejected at compile-time

f()
println(x) // prints 1
println(y) // rejected at compile-time

Most languages now use static scoping, with variations as to which programming language constructs introduce a new scope. Dynamic scoping, in contrast, is error-prone and has become less popular. It was used in the original Lisp and remains available as an option in modern variants of that language. It is also used in some scripting languages, most notably Perl and various Bourne Shell implementations.

As an illustration, this Scala program follows static scoping rules:

Scala

var x = 1

def f() =
   x += 1
   println(x) // prints 2

def g() =
   var x = 10
   f()

g()
println(x) // prints 2

Function g defines a local variable x, then invokes f. The variable x used inside function f, however, is the one declared on the first line of the program, which is the one in scope where function f is defined. The local variable with the same name defined inside function g plays no part. The behavior would be the same for an equivalent program written in Java, Kotlin, C, or any one of a multitude of languages that use static scoping.

Contrast this with the following Bash implementation:

Bash

x=1

f() {
  (( x++ ))
   printf "%d\n" $x  # prints 11
}

g() {
  local x=10
  f
}

g
printf "%d\n" $x  # prints 1

In Bash, the variable x used inside function f is not the variable in scope where f is defined, but the variable in scope where function f is invoked. This variable, equal to 10, is incremented to 11. The variable x declared at the beginning of the program was never modified.

Dynamic scoping can be used to override a global variable with a local variable, thus changing the behavior of a function. This is sometimes useful, and a similar behavior can be achieved in Scala through implicit arguments. For instance, by reusing the Formatter type from Section 9.5, a function can be defined to print an object with the default formatter in scope:

Scala

def printFormatted(any: Any)(using formatter: Formatter): Unit =
   formatter.println(any)

printFormatted("foo") // uses the default formatter in scope (there must be one)

Within a function—or any block of code that introduces its own scope—a different formatter can be specified:

Scala

given UpperCaseFormatter: Formatter = str => str.toUpperCase

printFormatted("foo") // prints "FOO"

This technique brings back some of the flexibility of dynamic scoping but is much safer: Function printFormatted is explicit in the fact that it allows a locally defined formatter to impact its behavior.

The code examples in this book do not rely much on implicit arguments, except on occasion in Part II. In particular, Scala tends to use implicit arguments to specify the thread pool on which to execute concurrent activities.