Add examples discussing partial function application.
Add examples and discussion about closures.
Add an example of repeated function parameters.

Scala allows you to indicate that the last parameters to a function
may be repeated. This allows clients to pass variable length argument
lists to the function. To denote a repeated parameter, place an
asterisk after the type of the parameter.

The echo() function can be called with zero to many String arguments.

Inside the function, the type of the repeated parameter is an Array of
the declared type of the parameter. Thus, the type of args inside the
echo function, which is declared as type "String*"
is actually Array[String].
Add an example of named arguments to functions.
Add an example of default parameter values to functions.
Add examples of tail-recursive and non-tail-recursive functions.

In order for Scala to make a tail-call optimization to your functions,
the recursive call must be in the tail position of the function, that
is, the recursive call must be the very last thing that happens in the
function.

In function boom(), the recursive call is not tail-recursive, because
there is a pending addition operation waiting to be applied to the
result of recursively calling boom with x - 1.

Hopefully the (real) captured stack traces of running these functions
in the scala console will help demonstrate what's going on under the
hood.
Mutual recursion is not tail-call optimizable.
Calling a recursive function through a value also frustrates tail-call optimization.
Add an example singleton object, FileMatcher.

It will be used to illustrate the power of higher-order functions.
Add a generator for files containing a query string.

Because, you know, sometimes you don't know what exactly your
files end in, so filesContaining lets you search in any position.
Some duplication is beginning to creep in...
Add a generator for files matching a regex.

Oh boy, the duplication is piling up now!
Add a generator that takes a matcher function.

The sole purpose of the matcher function is to check files names
against a query and return the result of the match. This method
is a generalization of the previous three, and they can be
simplified into ussages of this method.
Simplify the FileMatcher methods to use filesMatching.

Using the placeholder underscore syntax, each method specifies
how it wants to match file names, that is, the first underscore
is the filename of filesMatching, and the second parameter is
the query passed to it from the other three methods.
Reduce redundant parameter passing.

The filesMatching method was doing nothing with the query parameter,
except to pass it back to matcher, which came from a context which
was already known to the caller!

We can then reduce filesMatching to just take a matcher that just
takes a file name and returns a boolean indicating the match.
Each matcher passed already knows its own query, and filesMatching
need not be concerned with it.
Make FileMatcher.filesMatching a private method.

Unless such a time as it is needed externally, it is sufficient to
leave filesMatching a private method.