Functional Programming on Andrew Bancroft

Swift Functions as Types

Fri, 18 Mar 2016 18:11:02 +0000

For the well-versed functional programmer, the fact that [functions in Swift are Types][1] is no surprise. But I’m relatively new to the game on that front, so when I first encountered the idea of thinking of a function as a Type back when Swift was announced in 2014, it was a real eye-opener for me.

Swift Types (in general)

In order to understand functions as Types, it’s probably a good idea to know what folks are talking about when they use the term “Type” in a general sense.

In Swift, we’ve got two kinds of Types when we talk about them generally:

Named Types
Compound Types

Named Types

Named Types are those which are defined and identified by the name that they’re given. Classes, structs, enums, and protocols fit this category of Type.

To define a Named Type, you’d do something like this:

1class SomeNewClassType {}
2
3struct SomeNewStructType {}
4
5enum SomeNewEnumType {}
6
7protocol SomeNewProtocolType {}

Initializing instances of Types and using their properties and methods, passing them around to functions that require parameters of those Types, or setting them as values to properties of other Types are all pretty standard thoughts that come to mind when using named Types.

Compound Types

Compound Types, on the other hand, don’t have names. Rather, they have “signatures” that define and identify them as Types. Swift has two compound Types: functions and tuples.

Now I know what you might be thinking: “Functions have names!”

Indeed many do. But when we’re thinking about them in terms of their Type-ness, we’ve got to go beyond the name to the function’s “signature” characteristics.

The name of a function (or tuple, since they can be type-aliased) is simply how we refer to the function in code to execute it or pass it around as an argument.

The “signature” of the function, however, is the part that characterizes the function as a Type.

I want to analyze what I’m talking about when I refer to a function’s “signature”, because that really is as the heart of my goal for this blog entry…

Function Types

What exactly makes up a function’s Type-ness or “signature” as I’ve been calling it? Two things:

The Type(s) of its parameters
The Type that the function returns

Combining the Type(s) that the function receives as inputs, and the Type that it returns composes to give the function its Type / “signature”.

Reading a function’s Type

It always helps me to visualize, so take apart an example.

If you’ve lived long on the Internet, you’re bound to have run across a Star Wars name generator… Plug in your name, and maybe a birth year, and out comes some crazy “Star Wars name” for you.

The function definition (minus the body) might look like this:

1func generateStarWarsName(firstName: String, lastName: String, birthYear: Int) -> String { 
2    // ... 
3}

If someone were to ask you, “What is the generateStarWarsName function’s Type?”, you could answer: “generateStarWarsName is a function Type that has three parameters, the first two of Type String, the last of Type Int, and that returns a value of Type String.”

Wordy? Yes. But it does explain in precise terms what the function’s Type is.

Function Type notation

Rather than write out the paragraph describing the function’s Type, it’s far more convenient to indicate a the Type of a function using a standard notation. This notation is also the syntax that the Swift compiler uses when it’s trying to work with function Types.

Essentially, it boils down to stripping away the function’s name and the parameter names to leave behind the raw Type information that composes to give the function its Type.

Given the above generateStarWarsName function, we could notate its Type as follows:

(String, String, Int) -> String

See how that works?

Remove “generateStarWarsName”, “firstName: “, “lastName: “, and “birthYear: ” and you’re left with that raw Type information. What remains is the function’s Type notation.

It tells you (and the Swift compiler) everything you need to know to be able identify the Type of that function… it’s “signature”, if you will.

Gotchas

A couple of gotchas when it comes to notating a function’s Type:

1 – If a function takes no parameters, the “parameter portion” of the Type notation will simply be () with nothing between the parentheses.

So for example, the Type notation of
func returnHelloString() -> String {}
is () -> String.

2 – If a function has no return type (ie, it doesn’t return anything), the “return type portion” of the Type notation will be -> Void.

So for example, the Type notation of
func sayHello() {}
is () -> Void, since it takes no parameters, and returns nothing.

Practice

Here are a few more examples for you to practice function Type identification. Can you write out the correct notation for each function’s Type?

1func complimentMe(name: String) -> String { 
2    // ... 
3}

Show answer

`(String) -> String`

1func countToTen() { 
2    // ... prints 1 to 10 to the console ...
3}

Show answer

`() -> Void`

Notice that while `countToTen` doesn't have the "-> Void” in its definition, it is listed in the function's Type notation for clarity.

When you read this function's Type, you'd say, "This is a function Type which takes no parameters and returns Void.”

1func addInts(first: Int, second: Int) -> Int { 
2    // ... 
3}

Show answer

`(Int, Int) -> Int`

1func fadeIn(duration: NSTimeInterval, delay: NSTimeInterval, completion: (Bool) -> Void){ 
2    // ... 
3}

Show answer

`(NSTimeInterval, NSTimeInterval, (Bool) -> Void)) -> Void`

This one's actually a more complicated "compound Type” – note the third parameter which indicates that `fadeIn` receives a function Type as one of its inputs. Remember that since functions are Types, they carry the characteristic of being able to be passed around to other functions as parameters, or stored in variables/constants!

<p>
</p>

```swift

func increment(input: Int) -> Int { return input + 1 }

func decrement(input: Int) -> Int { return input - 1 }

func chooseAdjustmentFunction(increase: Bool) -> (Int) -> Int { return increase ? increment : decrement }

    
    <p>
      <a id="show-answer-5" style="cursor: pointer;">Show answer</a>
    </p>
    
    <div id="answer-5" style="display: none;">
      increment: `(Int) -> Int`<br /> decrement: `(Int) -> Int`</p> 
      
      <p>
        chooseAdjustmentFunction(_:): `(Bool) -> (Int) -> Int`
      </p>
      
      <p>
        This one's complicated in a slightly different way. This time, it's the return Type of the function that's kind of crazy.
      </p>
      
      <p>
        Read this as, "A function Type which takes as Bool as a parameter and returns a function Type which takes an Int as a parameter and returns an Int.&#8221;
      </p>
      
      <p>
        You can see how the Types of the `increment` and `decrement` functions <em>match</em> the return Type of the `chooseAdjustmentFunction` function. </div> 
        
        <h1>
          Wrapping up
        </h1>
        
        <p>
          Knowing that functions are Types in Swift is a powerful thing. Being able to correctly articulate the Type of a function, and produce its notation in valid Swift syntax is even <em>more</em> powerful, because it's at that point when you'll be able to recognize which kinds of functions are valid to pass as parameters to <em>other</em> functions, or to assign as properties of other Types. It can also play a role in Swift's pattern matching features. But alas, those topics for another day!
        </p>
        
        <p>
          <a name="related" class="jump-target"></a>
        </p>
        
        <div class="resources">
          <div class="resources-header">
            You might also enjoy&#8230;
          </div>
          
          <ul class="resources-content">
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/06/immutable-types-changing-state-swift/" title="Immutable Types with Changing State in Swift">Immutable Types with Changing State in Swift</a>
            </li>
            <li>
              <i class="fa fa-angle-right"></i> <a href="https://www.andrewcbancroft.com/2015/01/20/conveniently-transforming-immutable-types-swift/" title="Conveniently Transforming Immutable Types in Swift">Conveniently Transforming Immutable Types in Swift</a>
            </li>
          </ul>
        </div>
        
        <p>
          <a name="share" class="jump-target"></a>
        </p>
        
        <p>
        </p>

 [1]: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html#//apple_ref/doc/uid/TP40014097-CH10-ID158

Conveniently Transforming Immutable Types in Swift

Tue, 20 Jan 2015 12:30:51 +0000

A few weeks ago I wrote about Immutable Types and Changing State in Swift, where I hoped to convey an “aha!-moment” that happened for me.

Since then, I’ve learned a bit more. For example, the technique I presented for transforming instances of a Type immutably actually come for free when you use a value Type, such as a Struct! Check out @NatashaTheRobot’s writeup on the subject, titled “Mutating Functions in Swift Structs”, for more information.

But let’s say, for whatever reason, you’d like to use a reference Type, such as a Class. In that case, the technique I presented in the aforementioned blog entry works out quite nicely. Until….

Many init parameters == Pain

… It works great right up until you have more than a few immutable properties that you need to transform.

I want to thank @Jarsen for his comment. He pointed out the exact pain point I was feeling, since I was actually using my own advice in a personal project. Not only that, he offers a solution in the form of a GitHub gist!

I’m bringing in his example so that we have it before us with a few minor modifications to make it relevant for this blog entry. However, I want to give 100% credit to Jarsen for his insight.

It’s all about convenience

The gist of Jarsen’s solution was to create a second helper initializer which would help setting the values for all the properties easier. Take a look:

 1class Scorekeeper {
 2    let runningScore: Int
 3    let climbingScore: Int
 4    // potentially more properties
 5    
 6    init(runningScore: Int = 0, climbingScore: Int = 0) {
 7        self.runningScore = runningScore
 8        self.climbingScore = climbingScore
 9    }
10    
11    // second helper initializer
12    init(scoreKeeper: Scorekeeper, runningScore: Int? = nil, climbingScore: Int? = nil) {
13        self.runningScore = runningScore ?? scoreKeeper.runningScore
14        self.climbingScore = climbingScore ?? scoreKeeper.climbingScore
15    }
16    
17    func incrementRunningScoreBy(points: Int) -> Scorekeeper {
18        return Scorekeeper(scoreKeeper: self, runningScore: self.runningScore + points)
19    }
20    
21    // other functions to transform Scorekeeper by incrementing other score properties
22}

Note the use of optionals, and the corresponding nil-coalescing operator (??) in the helper initializer’s implementation. It’s simple, and it’s concise. I like it!

The bottom line is that I couldn’t help but share Jarsen’s tip. I thought it deserved a little more attention than to be stuck down in the comment section where folks may or may not find it and be helped.

Immutable Types with Changing State in Swift

Tue, 06 Jan 2015 12:00:50 +0000

Dabble in Swift for long and the functional programming paradigm will most certainly appear on your radar. From conferences to books to blog posts, I’ve seen a lot in the functional programming arena as it relates to Swift.

As I seek to improve my functional programming thought processes and to practice what I’m learning, I found myself struggling with a fundamental concept: immutability. Especially when I’m designing something that, at the very least, appears to require the ability to change state at some point in time.

Immutable changes – A contradiction in terms?

Immutability and changing state was a real struggle for me. The two seemed contradictory actually. How am I supposed to handle changes with things that can’t change??!

And then, with the help of Stack Overflow, a lightbulb came on. As I was perusing FP topics, I ran across a question that expressed exactly what I was feeling. “How can you do anything useful without mutable state?”, the questioner asked. The answer is what illuminated things for me. The key quote from the Stack Overflow answer:

In functional languages, rather than mutating the state of objects, we simply return a new object with the changes we want.

So… instead of thinking about state changes as mutations, think of them as reasons to create something new.

Getting practical with Swift

If I’m going to get pragmatic with this, I have some design decisions to make if I’m going to try and avoid mutating the state of my objects. Rather than design my Types with the intent to update stored properties in-place, I should think about designing them so that the state-change process would actually produce a whole new instance with the transformed (updated) value.

See it in action

I’m a visual person, so for those of you who need to see it in action like me, here’s a short example: Suppose that you’re designing a class that stores a counter (or a score or a total… something like that), and provides a function to let you increment that count.

The mutating way

We could design this class in one of two ways: declare a variable stored property to hold the count. The method would then reassign incremented values to it. This is the opposite of immutable changes:

class Scorekeeper {
    var runningScore: Int
    
    init (score: Int = 0) {
        self.runningScore = score
    }
    
    func incrementScoreBy(points: Int) {
        runningScore += points
    }
}

let scoreKeeper = Scorekeeper()
scoreKeeper.incrementScoreBy(5)
println(scoreKeeper.runningScore)
// prints 5

    <p></p>
    
    
    ### The immutable way
    
    
    OR, rather than mutating the existing variable, we could go an alternate route:  The second way to design the class is to declare a constant stored property.  The method would then produce _new_ instance that stored the new state:
    
    
        class Scorekeeper {
            let runningScore: Int
            
            init (score: Int = 0) {
                self.runningScore = score
            }
            
            func incrementScoreBy(points: Int) -> Scorekeeper {
                return Scorekeeper(score: self.runningScore + points)
            }
        }
        
        let scorekeeper = Scorekeeper()
        let scorekeeperWithIncreasedScore = scorekeeper.incrementScoreBy(5)
        println(scorekeeperWithIncreasedScore.runningScore)
        // prints 5

    <p></p>
    
    
    ### Observations
    
    
    As I look at the code I've just presented, I notice a few things as I contrast the two examples:
    
    
    
    
    
      * The first example uses var to declare the stored property of my Scorekeeper class.  It _has_ to be var so that the value of the property can be changed (mutated).
    
    
      * The second example uses let exclusively.  No in-place mutations occur, so constants are perfectly reasonable to use.
    
    
    
    * * *
    
    
    
    
    
      * The first example's design lends itself to produce interesting and unpredictable side-effects.  If multiple clients hold a reference to my scorekeeper instance, there are two ways for the runningScore to change out from underneath any of those clients:  First, I could simply reassign a value to the runningScore directly.  Second, I could call incrementScoreBy().  Either way, unintended consequences may arise because of the mutation.
    
    
      * In the second example, it's _impossible_ to cause those unintended consequences.  runningScore can't be changed directly (it's a constant), and incrementScoreBy() returns a whole _new_ instance, so all clients would be dealing with the instance that they expect to be dealing with.  No values can be changed out from underneath them.
    
    
    
    * * *
    
    
    
    
    
      * The first example's incrementScoreBy method has no return value.  While I can envision writing a unit test for this, it's not obvious at first glance what I should do.  The method produces a side-effect in my existing instance that I need to know about in order to get the XCTAssert right.
    
    
      * The second example's incrementScoreBy method returns a new Scorekeeper instance.  The unit test for this (to me) is a little more clear.  I simply inspect the value of runningScore of the new instance, and assert that it is [x] points higher than the old instance.  I still have both the old scorekeeper instance _and_ the new scorekeeperWithIncreasedScore, so everything I'd need to ensure the correct point increase occurred is at my disposal.
    
    
    
    ### Conclusion
    
    
    I hear so much benefit that comes from avoiding mutable state, so it was satisfying to finally let my mind reconcile how to manage the state of my own Types immutably.  With the iOS frameworks we have to work with, immutability is a challenge, and _total_ immutable state is not possible (think of the user interface layer where state is stored and updated out of necessity because of how _Apple's_ frameworks and tools are designed). Nonetheless, I found this discovery to be really exciting all the same.

Resolving “Variable used within its own initial value” Error in Swift

Mon, 20 Oct 2014 13:50:52 +0000

While experimenting with a few things today, I experienced this compiler error:

Variable used within its own initial value

Let me describe the situation I was in…

I was playing (in a playground, no less) with closures, trying to mimic some behavior that I’ve recently learned about in Scala. Essentially, I was trying to implement a factorial function as a closure, and I was trying to do it recursively (that is, without using a for/while loop). Here’s what I wanted to do:

1let factorial = {
2    (n: Int) -> Int in
3    if (n == 0) {
4        return 1
5    } else {
6        return n * factorial(n - 1)
7    }
8}

If you’ve seen factorial before, the above implementation isn’t new. The “base case” that will let the recursion stop is the expression if (n == 0), and the recursive case is in the else block, where factorial gets called again within its own body’s definition. Only problem is… this doesn’t work in Swift 1.0.

Apparently, the closure (which is being initialized and assigned to the constant named “factorial”) hasn’t had a chance to fully initialize itself before the name factorial is used within the body.

The frustrating part is that I really didn’t want to type the letters v-a-r to implement my solution. But alas, as Stack Overflow says, the following solution to the “initial value” error works:

 1var factorial: (Int) -> Int
 2factorial = {
 3    (n: Int) -> Int in
 4    if (n == 0) {
 5        return 1
 6    } else {
 7        return n * factorial(n - 1)
 8    }
 9}
10
11factorial(5)
12// Produces the correct result of 120

Of course, there’s absolutely no reason for the implementation to be a closure – I was simply experimenting. Here’s the solution that I actually prefer… a good ole named function definition:

 1func factorial(n: Int) -> Int {
 2    if (n == 0) {
 3        return 1
 4    } else {
 5        return n * factorial(n - 1)
 6    }
 7}
 8
 9factorial(5)
10// Produces the correct result of 120