We are all embracing some functional styles in our imperative code. Sometimes we just do not
notice it. Consider a user-defined **List **class:

class List<T> {

// …

fun contains(t: T): Boolean { … }

}

and a typical usage:

val xs: List<Int> = …

if(xs.contains(5)) …

Function literals make the member function **contains **more useful:

class List<T> {
// ...
fun contains(t: T): Boolean { ... }
fun contains(predicate: (T) -> Boolean): Boolean { ... }
}

Now the definition expects a function that seeks a match. The usage is now:

val xs: List<Int> = …

if(xs.contains({t -> (t == 5)})) …

But the definition now lets us ask other questions of the List:

if(xs.contains({t -> (t < 0)})) … // any negative value?

if(xs.contains({t -> (t % 2 == 0)})) … // any even-valued value?

The member function **contains **is now an example of a higher-order function - one that

accepts a function parameter. Other higher-order functions return function values. Its a

short step from there to using curried functions, partial function application, functions as

class properties, and on to an ever increasing usage of a functional style in an imperative

setting.