Scala Reassignment To Val Function Parameters

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 9.2, “How to use functions as variables (values) in Scala.”

Back to top

Problem

You want to pass a Scala function around like a variable, just like you pass , , and other variables around in an object-oriented programming language.

Back to top

Solution

Use the syntax shown in Recipe 9.1 to define a function literal, and then assign that literal to a variable.

The following Scala code defines a function literal that takes an parameter and returns a value that is twice the amount of the that is passed in:

(i: Int) => { i * 2 }

As mentioned in Recipe 9.1, you can think of the symbol as a transformer. In this case, the function transforms the value to an value that is twice the value of .

You can now assign that function literal to a variable:

val double = (i: Int) => { i * 2 }

The variable is an instance, just like an instance of a , , or other type, but in this case, it’s an instance of a function, known as a function value. You can now invoke just like you’d call a method:

double(2) // 4 double(3) // 6

Beyond just invoking like this, you can also pass it to any method (or function) that takes a function parameter with its signature. For instance, because the method of a sequence is a generic method that takes an input parameter of type and returns a type , you can pass the method into the method of an sequence:

scala> val list = List.range(1, 5) list: List[Int] = List(1, 2, 3, 4) scala> list.map(double) res0: List[Int] = List(2, 4, 6, 8)

Welcome to the world of functional programming.

Back to top

Discussion

You can declare a function literal in at least two different ways. I generally prefer the following approach, which implicitly infers that the following function’s return type is :

val f = (i: Int) => { i % 2 == 0 }

In this case, the Scala compiler is smart enough to look at the body of the function and determine that it returns a value. As a human, it’s also easy to look at the code on the right side of the expression and see that it returns a , so I usually leave the explicit return type off the function declaration.

However, if you prefer to explicitly declare the return type of a function literal, or want to do so because your function is more complex, the following examples show different forms you can use to explicitly declare that your function returns a :

val f: (Int) => Boolean = i => { i % 2 == 0 } val f: Int => Boolean = i => { i % 2 == 0 } val f: Int => Boolean = i => i % 2 == 0 val f: Int => Boolean = _ % 2 == 0

A second example helps demonstrate the difference of these approaches. These functions all take two parameters and return a single value, which is the sum of the two input values:

// implicit approach val add = (x: Int, y: Int) => { x + y } val add = (x: Int, y: Int) => x + y // explicit approach val add: (Int, Int) => Int = (x,y) => { x + y } val add: (Int, Int) => Int = (x,y) => x + y

As shown, the curly braces around the body of the function in these simple examples are optional, but they are required when the function body grows to more than one expression:

val addThenDouble: (Int, Int) => Int = (x,y) => { val a = x + y 2 * a }Back to top

Using a method like an anonymous function

Scala is very flexible, and just like you can define an anonymous function and assign it to a variable, you can also define a method and then pass it around like an instance variable. Again using a modulus example, you can define a method in any of these ways:

def modMethod(i: Int) = i % 2 == 0 def modMethod(i: Int) = { i % 2 == 0 } def modMethod(i: Int): Boolean = i % 2 == 0 def modMethod(i: Int): Boolean = { i % 2 == 0 }

Any of these methods can be passed into collection methods that expect a function that has one parameter and returns a , such as the method of a :

val list = List.range(1, 10) list.filter(modMethod)

Here’s what that looks like in the REPL:

scala> def modMethod(i: Int) = i % 2 == 0 modMethod: (i: Int)Boolean scala> val list = List.range(1, 10) list: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8, 9) scala> list.filter(modMethod) res0: List[Int] = List(2, 4, 6, 8)

As noted, this is similar to the process of defining a function literal and assigning it to a variable. The following function works just like the previous method:

val modFunction = (i: Int) => i % 2 == 0 list.filter(modFunction)

At a coding level, the obvious difference is that is a method defined in a class, whereas is a function that’s assigned to a variable. Under the covers, is an instance of the trait, which defines a function that takes one argument. (The scala package defines other similar traits, including , , and so on, up to .)

Back to top

Assigning an existing function/method to a function variable

Continuing our exploration, you can assign an existing method or function to a function variable. For instance, you can create a new function named from the scala.math.cos method using either of these approaches:

scala> val c = scala.math.cos _ c: Double => Double = <function1> scala> val c = scala.math.cos(_) c: Double => Double = <function1>

This is called a partially applied function. It’s partially applied because the method requires one argument, which you have not yet supplied (more on this in Recipe 9.6).

Now that you have , you can use it just like you would have used :

scala> c(0) res0: Double = 1.0

If you’re not familiar with this syntax, this is a place where the REPL can be invaluable. If you attempt to assign the function/method to a variable, the REPL tells you what’s wrong:

scala> val c = scala.math.cos <console>:11: error: missing arguments for method cos in class MathCommon; follow this method with `_' to treat it as a partially applied function val c = scala.math.cos ^

The following example shows how to use this same technique on the scala.math.pow method, which takes two parameters:

scala> val p = scala.math.pow(_, _) pow: (Double, Double) => Double = <function2> scala> p(scala.math.E, 2) res0: Double = 7.3890560989306495

If this seems like an interesting language feature, but you’re wondering where it would be useful, see Recipe 9.6, “Using Partially Applied Functions”, for more information.

Back to top

Summary notes

  • Think of the symbol as a transformer. It transforms the input data on its left side to some new output data, using the algorithm on its right side.
  • Use to define a method, to create a function.
  • When assigning a function to a variable, a function literal is the code on the right side of the expression.
  • A function value is an object, and extends the traits in the main scala package, such as for a function that takes no parameters.
Back to top

See Also

Back to top

The Scala Cookbook

This tutorial is sponsored by the Scala Cookbook, which I wrote for O’Reilly:

You can find the Scala Cookbook at these locations:

Back to top

Basic Declarations and Definitions

A declaration introduces names and assigns them types. It can form part of a class definition or of a refinement in a compound type.

A definition introduces names that denote terms or types. It can form part of an object or class definition or it can be local to a block. Both declarations and definitions produce bindings that associate type names with type definitions or bounds, and that associate term names with types.

The scope of a name introduced by a declaration or definition is the whole statement sequence containing the binding. However, there is a restriction on forward references in blocks: In a statement sequence $s_1 \ldots s_n$ making up a block, if a simple name in $s_i$ refers to an entity defined by $s_j$ where $j \geq i$, then for all $s_k$ between and including $s_i$ and $s_j$,

  • $s_k$ cannot be a variable definition.
  • If $s_k$ is a value definition, it must be lazy.

Value Declarations and Definitions

A value declaration introduces $x$ as a name of a value of type $T$.

A value definition defines $x$ as a name of the value that results from the evaluation of $e$. If the value definition is not recursive, the type $T$ may be omitted, in which case the packed type of expression $e$ is assumed. If a type $T$ is given, then $e$ is expected to conform to it.

Evaluation of the value definition implies evaluation of its right-hand side $e$, unless it has the modifier . The effect of the value definition is to bind $x$ to the value of $e$ converted to type $T$. A value definition evaluates its right hand side $e$ the first time the value is accessed.

A constant value definition is of the form

where is a constant expression. The modifier must be present and no type annotation may be given. References to the constant value are themselves treated as constant expressions; in the generated code they are replaced by the definition's right-hand side .

Value definitions can alternatively have a pattern as left-hand side. If $p$ is some pattern other than a simple name or a name followed by a colon and a type, then the value definition is expanded as follows:

  1. If the pattern $p$ has bound variables $x_1 , \ldots , x_n$, where $n > 1$:

Here, $\$ x$ is a fresh name.

  1. If $p$ has a unique bound variable $x$:
  1. If $p$ has no bound variables:
Example

The following are examples of value definitions

The last two definitions have the following expansions.

The name of any declared or defined value may not end in .

A value declaration is a shorthand for the sequence of value declarations . A value definition is a shorthand for the sequence of value definitions . A value definition is a shorthand for the sequence of value definitions .

Variable Declarations and Definitions

A variable declaration is equivalent to the declarations of both a getter function $x$ and a setter function:

An implementation of a class may define a declared variable using a variable definition, or by defining the corresponding setter and getter methods.

A variable definition introduces a mutable variable with type $T$ and initial value as given by the expression $e$. The type $T$ can be omitted, in which case the type of $e$ is assumed. If $T$ is given, then $e$ is expected to conform to it.

Variable definitions can alternatively have a pattern as left-hand side. A variable definition where $p$ is a pattern other than a simple name or a name followed by a colon and a type is expanded in the same way as a value definition, except that the free names in $p$ are introduced as mutable variables, not values.

The name of any declared or defined variable may not end in .

A variable definition can appear only as a member of a template. It introduces a mutable field with type $T$ and a default initial value. The default value depends on the type $T$ as follows:

defaulttype $T$
or one of its subrange types
all other types

When they occur as members of a template, both forms of variable definition also introduce a getter function $x$ which returns the value currently assigned to the variable, as well as a setter function which changes the value currently assigned to the variable. The functions have the same signatures as for a variable declaration. The template then has these getter and setter functions as members, whereas the original variable cannot be accessed directly as a template member.

Example

The following example shows how properties can be simulated in Scala. It defines a class of time values with updatable integer fields representing hours, minutes, and seconds. Its implementation contains tests that allow only legal values to be assigned to these fields. The user code, on the other hand, accesses these fields just like normal variables.

A variable declaration is a shorthand for the sequence of variable declarations . A variable definition is a shorthand for the sequence of variable definitions . A variable definition is a shorthand for the sequence of variable definitions .

Type Declarations and Type Aliases

A type declaration declares $t$ to be an abstract type with lower bound type $L$ and upper bound type $U$. If the type parameter clause is omitted, $t$ abstracts over a first-order type, otherwise $t$ stands for a type constructor that accepts type arguments as described by the type parameter clause.

If a type declaration appears as a member declaration of a type, implementations of the type may implement $t$ with any type $T$ for which $L <: T <: U$. It is a compile-time error if $L$ does not conform to $U$. Either or both bounds may be omitted. If the lower bound $L$ is absent, the bottom type is assumed. If the upper bound $U$ is absent, the top type is assumed.

A type constructor declaration imposes additional restrictions on the concrete types for which $t$ may stand. Besides the bounds $L$ and $U$, the type parameter clause may impose higher-order bounds and variances, as governed by the conformance of type constructors.

The scope of a type parameter extends over the bounds and the type parameter clause $\mathit{tps}$ itself. A higher-order type parameter clause (of an abstract type constructor $tc$) has the same kind of scope, restricted to the declaration of the type parameter $tc$.

To illustrate nested scoping, these declarations are all equivalent: , and , as the scope of, e.g., the type parameter of $m$ is limited to the declaration of $m$. In all of them, $t$ is an abstract type member that abstracts over two type constructors: $m$ stands for a type constructor that takes one type parameter and that must be a subtype of $Bound$, $t$'s second type constructor parameter. is a valid use of $t$.

A type alias defines $t$ to be an alias name for the type $T$. The left hand side of a type alias may have a type parameter clause, e.g. . The scope of a type parameter extends over the right hand side $T$ and the type parameter clause $\mathit{tps}$ itself.

The scope rules for definitions and type parameters make it possible that a type name appears in its own bound or in its right-hand side. However, it is a static error if a type alias refers recursively to the defined type constructor itself. That is, the type $T$ in a type alias may not refer directly or indirectly to the name $t$. It is also an error if an abstract type is directly or indirectly its own upper or lower bound.

Example

The following are legal type declarations and definitions:

The following are illegal:

If a type alias refers to a class type $S$, the name $t$ can also be used as a constructor for objects of type $S$.

Example

The object contains a definition which establishes as an alias of the parameterized class :

As a consequence, for any two types $S$ and $T$, the type is equivalent to the type . can also be used as a constructor instead of , as in:

Type Parameters

Type parameters appear in type definitions, class definitions, and function definitions. In this section we consider only type parameter definitions with lower bounds and upper bounds whereas a discussion of context bounds and view bounds is deferred to here.

The most general form of a first-order type parameter is . Here, $L$, and $U$ are lower and upper bounds that constrain possible type arguments for the parameter. It is a compile-time error if $L$ does not conform to $U$. $\pm$ is a variance, i.e. an optional prefix of either , or . One or more annotations may precede the type parameter.

The names of all type parameters must be pairwise different in their enclosing type parameter clause. The scope of a type parameter includes in each case the whole type parameter clause. Therefore it is possible that a type parameter appears as part of its own bounds or the bounds of other type parameters in the same clause. However, a type parameter may not be bounded directly or indirectly by itself.

A type constructor parameter adds a nested type parameter clause to the type parameter. The most general form of a type constructor parameter is .

The above scoping restrictions are generalized to the case of nested type parameter clauses, which declare higher-order type parameters. Higher-order type parameters (the type parameters of a type parameter $t$) are only visible in their immediately surrounding parameter clause (possibly including clauses at a deeper nesting level) and in the bounds of $t$. Therefore, their names must only be pairwise different from the names of other visible parameters. Since the names of higher-order type parameters are thus often irrelevant, they may be denoted with a , which is nowhere visible.

Example

Here are some well-formed type parameter clauses:

The following type parameter clauses are illegal:

Variance Annotations

Variance annotations indicate how instances of parameterized types vary with respect to subtyping. A ‘+’ variance indicates a covariant dependency, a ‘-’ variance indicates a contravariant dependency, and a missing variance indication indicates an invariant dependency.

A variance annotation constrains the way the annotated type variable may appear in the type or class which binds the type parameter. In a type definition , or a type declaration type parameters labeled ‘+’ must only appear in covariant position whereas type parameters labeled ‘-’ must only appear in contravariant position. Analogously, for a class definition , type parameters labeled ‘+’ must only appear in covariant position in the self type $S$ and the template $T$, whereas type parameters labeled ‘-’ must only appear in contravariant position.

The variance position of a type parameter in a type or template is defined as follows. Let the opposite of covariance be contravariance, and the opposite of invariance be itself. The top-level of the type or template is always in covariant position. The variance position changes at the following constructs.

  • The variance position of a method parameter is the opposite of the variance position of the enclosing parameter clause.
  • The variance position of a type parameter is the opposite of the variance position of the enclosing type parameter clause.
  • The variance position of the lower bound of a type declaration or type parameter is the opposite of the variance position of the type declaration or parameter.
  • The type of a mutable variable is always in invariant position.
  • The right-hand side of a type alias is always in invariant position.
  • The prefix $S$ of a type selection is always in invariant position.
  • For a type argument $T$ of a type : If the corresponding type parameter is invariant, then $T$ is in invariant position. If the corresponding type parameter is contravariant, the variance position of $T$ is the opposite of the variance position of the enclosing type .

References to the type parameters in object-private or object-protected values, types, variables, or methods of the class are not checked for their variance position. In these members the type parameter may appear anywhere without restricting its legal variance annotations.

Example

The following variance annotation is legal.

With this variance annotation, type instances of $P$ subtype covariantly with respect to their arguments. For instance,

If the members of $P$ are mutable variables, the same variance annotation becomes illegal.

If the mutable variables are object-private, the class definition becomes legal again:

Example

The following variance annotation is illegal, since $a$ appears in contravariant position in the parameter of :

The problem can be avoided by generalizing the type of by means of a lower bound:

Example

With that annotation, we have that conforms to . That is, a channel on which one can write any object can substitute for a channel on which one can write only strings.

Function Declarations and Definitions

A function declaration has the form , where $f$ is the function's name, $\mathit{psig}$ is its parameter signature and $T$ is its result type. A function definition also includes a function body $e$, i.e. an expression which defines the function's result. A parameter signature consists of an optional type parameter clause , followed by zero or more value parameter clauses . Such a declaration or definition introduces a value with a (possibly polymorphic) method type whose parameter types and result type are as given.

The type of the function body is expected to conform to the function's declared result type, if one is given. If the function definition is not recursive, the result type may be omitted, in which case it is determined from the packed type of the function body.

A type parameter clause $\mathit{tps}$ consists of one or more type declarations, which introduce type parameters, possibly with bounds. The scope of a type parameter includes the whole signature, including any of the type parameter bounds as well as the function body, if it is present.

A value parameter clause $\mathit{ps}$ consists of zero or more formal parameter bindings such as or , which bind value parameters and associate them with their types.

Default Arguments

Each value parameter declaration may optionally define a default argument. The default argument expression $e$ is type-checked with an expected type $T'$ obtained by replacing all occurrences of the function's type parameters in $T$ by the undefined type.

For every parameter $p_{i,j}$ with a default argument a method named is generated which computes the default argument expression. Here, $n$ denotes the parameter's position in the method declaration. These methods are parametrized by the type parameter clause and all value parameter clauses preceding $p_{i,j}$. The methods are inaccessible for user programs.

Example

In the method

the default expression is type-checked with an undefined expected type. When applying , the default value is inserted and is instantiated to . The methods computing the default arguments have the form:

The scope of a formal value parameter name $x$ comprises all subsequent parameter clauses, as well as the method return type and the function body, if they are given. Both type parameter names and value parameter names must be pairwise distinct.

A default value which depends on earlier parameters uses the actual arguments if they are provided, not the default arguments.

By-Name Parameters

The type of a value parameter may be prefixed by , e.g. . The type of such a parameter is then the parameterless method type . This indicates that the corresponding argument is not evaluated at the point of function application, but instead is evaluated at each use within the function. That is, the argument is evaluated using call-by-name.

The by-name modifier is disallowed for parameters of classes that carry a or prefix, including parameters of case classes for which a prefix is implicitly generated. The by-name modifier is also disallowed for implicit parameters.

Example

The declaration

indicates that both parameters of are evaluated using call-by-name.

Repeated Parameters

The last value parameter of a parameter section may be suffixed by , e.g. . The type of such a repeated parameter inside the method is then the sequence type . Methods with repeated parameters take a variable number of arguments of type $T$. That is, if a method $m$ with type is applied to arguments $(e_1 , \ldots , e_k)$ where $k \geq n$, then $m$ is taken in that application to have type $(p_1:T_1 , \ldots , p_n:T_n, p_s:S , \ldots , p_{s'}S)U$, with $k - n$ occurrences of type $S$ where any parameter names beyond $p_s$ are fresh. The only exception to this rule is if the last argument is marked to be a sequence argument via a type annotation. If $m$ above is applied to arguments , then the type of $m$ in that application is taken to be .

It is not allowed to define any default arguments in a parameter section with a repeated parameter.

Example

The following method definition computes the sum of the squares of a variable number of integer arguments.

The following applications of this method yield , , , in that order.

Furthermore, assume the definition:

The following application of method is ill-formed:

By contrast, the following application is well formed and yields again the result :

Procedures

Special syntax exists for procedures, i.e. functions that return the value . A procedure declaration is a function declaration where the result type is omitted. The result type is then implicitly completed to the type. E.g., is equivalent to .

A procedure definition is a function definition where the result type and the equals sign are omitted; its defining expression must be a block. E.g., is equivalent to .

Example

Here is a declaration and a definition of a procedure named :

The code above is implicitly completed to the following code:

Method Return Type Inference

A class member definition $m$ that overrides some other function $m'$ in a base class of $C$ may leave out the return type, even if it is recursive. In this case, the return type $R'$ of the overridden function $m'$, seen as a member of $C$, is taken as the return type of $m$ for each recursive invocation of $m$. That way, a type $R$ for the right-hand side of $m$ can be determined, which is then taken as the return type of $m$. Note that $R$ may be different from $R'$, as long as $R$ conforms to $R'$.

Example

Assume the following definitions:

Here, it is OK to leave out the result type of in , even though the method is recursive.

Import Clauses

An import clause has the form where $p$ is a stable identifier and $I$ is an import expression. The import expression determines a set of names of importable members of $p$ which are made available without qualification. A member $m$ of $p$ is importable if it is not object-private. The most general form of an import expression is a list of import selectors

for $n \geq 0$, where the final wildcard may be absent. It makes available each importable member under the unqualified name $y_i$. I.e. every import selector renames to $y_i$. If a final wildcard is present, all importable members $z$ of $p$ other than are also made available under their own unqualified names.

Import selectors work in the same way for type and term members. For instance, an import clause renames the term name to the term name $y$ and the type name to the type name $y$. At least one of these two names must reference an importable member of $p$.

If the target in an import selector is a wildcard, the import selector hides access to the source member. For instance, the import selector “renames” $x$ to the wildcard symbol (which is unaccessible as a name in user programs), and thereby effectively prevents unqualified access to $x$. This is useful if there is a final wildcard in the same import selector list, which imports all members not mentioned in previous import selectors.

The scope of a binding introduced by an import-clause starts immediately after the import clause and extends to the end of the enclosing block, template, package clause, or compilation unit, whichever comes first.

Several shorthands exist. An import selector may be just a simple name $x$. In this case, $x$ is imported without renaming, so the import selector is equivalent to . Furthermore, it is possible to replace the whole import selector list by a single identifier or wildcard. The import clause is equivalent to , i.e. it makes available without qualification the member $x$ of $p$. The import clause is equivalent to , i.e. it makes available without qualification all members of $p$ (this is analogous to in Java).

An import clause with multiple import expressions is interpreted as a sequence of import clauses .

Example

Consider the object definition:

Then the block

is equivalent to the block

0 thoughts on “Scala Reassignment To Val Function Parameters

Leave a Reply

Your email address will not be published. Required fields are marked *