In my previous post, I introduced ReactiveCocoa and went over the basic steps of creating a SignalProducer. I showed how you can process the events via the pipe forward operator |>, and teased a little at the end about the various functional compositions you can work with. What I did not go into was how to react to those events. Given that this is functional reactive programming that we’re talking about, perhaps a follow-up on that is not the worst idea.

Even if it’s three weeks overdue.

• • • • •

As I discussed, events come in four varieties: .Next(T), .Error(E), .Completed, and .Interrupted. Working with a Signal (which remember, has neither beginning nor end), we listen for those events by observing them:

someSignal.observe(next: {
    data in
        displayData(data)
})

Signals typically don’t have errors and don’t terminate, so that’s all we need to do for most signals.

Sign...

A lot of the posts I’ve written so far are by and large foundational work. They are, so to speak, table stakes for functional programming. But once at the table, it’s hard to know exactly where to go. There are many great articles on using these principles to, e.g., parse JSON, but at the end of the day, that’s one problem, there are solid solutions out there, and it doesn’t need to be solved again. Parsing JSON is hardly a reason to adopt functional programming wholesale. Functional programming should help you write better code.

Over the past couple of months, our team at work has been developing an application in pure Swift using the pre-release versions of ReactiveCocoa, and it has been a complete joy. We have been able to test far more of our code than ever before in unit tests, we have been able to break it into tiny functions that are easy to review on their own, and we have been...

The answer — by demonstration — would take care of that, too.

 — Isaac Asimov, The Last Question

From time to time, I stumble across something beautiful and true. It happened recently, and this is me trying to share it. It has a formal name, the Curry-Howard correspondence, but it’s one of those rare bits of knowledge that, once known, feel so inevitable, they almost don’t need a name. It may not impress you as deeply as it did me; you may not see the point; you may not care. But it is the most profound and elegant thing I know about programming.

• • • • •

Programming is an act of creation. Constrained by business needs, by hardware limitations, by our own reach which may exceed our grasp, we are still, in the end, creators. But — we are not artists. There is elegance in what we do; it is not the goal. There can be beauty in the product; it is subordinate to function. There can...

A few years ago, Steve Yegge wrote a great piece arguing that software developers can be divided into conservatives and liberals, and moreover that, like in politics, there are some issues where the dividing lines are very clear. The first issue on his list was type systems. Given how different Swift’s type system is from Objective-C’s, I’m going to take a more general look at types as a concept. You’ll find that, like many people who were enthusiastic about Swift from the get-go, I am a software conservative on this issue.

The prototypical example of a liberal language is Ruby. Ruby has no compile-time type checking. As long as your syntax looks like it belongs to a Ruby program, the interpreter will happily load it and try to do something with it — but it will crash your app if you messed up  and tried to add a Restaurant and a PoisonDart (you have an interesting problem space).

The...

I’ve been holed up dealing with Metal for a bit (which I was completely unfamiliar with, and therefore unable to blog about), but Swift 1.2 came out last week, rousing me out of my graphics-induced coma. And boy was I in for a surprise. Remember my posts on monads, and all my talk of Magical Future Swift? It’s here!

Well…almost.

• • • • •

A brief recap for those who don’t remember: I motivated my discussion of Magical Future Swift by talking about the nested optionals problem, wherein Birthday Beth wants to have a super fun birthday party, but only if all of her friends show up:

func partyGameForFriend1(friend1:Friend?,
                        friend2:Friend?, 
                        friend3:Friend?) -> Game {
    if let f1 = friend1 {
        if let f2 = friend2 {
            if let f3 = friend3 {
                return Game.Superfun(f1, f2, f3)
            }
        }
    }

So Swift 1.0 has come and gone, and Swift 1.1 is just around the corner. As we’re getting closer to a more stable shape for the language, I’m interested in its potential as a scripting language for OS X. In case you missed it, Swift can be used as a scripting language by invoking it via the good old-fashioned shebang syntax:

!/usr/bin/env xcrun swift

import Foundation

… // do the things

However, being able to invoke it and being able to do something useful with it are two very different issues. Swift is not yet ready for useful scripting — but I think it has the potential.

• • • • •

Brevity is the soul of scripting. There are a few things any scripting language needs to get right, to support out-of-the-box in a solid and reasonably intuitive sense. They are:

• File I/O (including file system traversal, permissions, and of course reading and writing)
• String manipulation  (including...

After spending most of the summer delving into what Swift can and can’t do as a functional programming language, I’ve turned my attention to writing real library code in Swift. I do have a day job, after all, and while thinking about Magical Future Swift is a fun exercise, I still need to learn how to do the basic everyday things. Which is where I was tripped up by the default framework test settings.

The issue occurred when I created a new Cocoa framework project, in Swift. By default these come with tests, so you’d be forgiven for thinking that the tests just run when you type Cmd-U, as they would for an app. You would be wrong, however. Most of the “Product” menu is disabled and gives that heart-sinking “you can’t do what you think you can do” sound when you try the shortcuts.

What happens is that by default, the test bundle is not added to the test configuration of the framework’s...

The third monad law declares that the following identity must hold for a monad M, where a:M<A>, f: A -> M<B>, and g: B -> M<C>:

(a >>=- f) >>=- g   ==   a >>=- { b in f(x) >>=- g }

To motivate this, we first want to show that the snippet below is a form of the left-hand-side of the identity:

// Form 1
let val = for {
    b <- for {
             ignore <- doSomething()
             b1 <- doSomething()
         } yield {
             b1
         }
    c <- process(b) // process(val:Int?) -> Int?
} yield {
    c
}

Then we want to show that Form 2 below is a form of the right-hand-side:

// Form 2
let val = for {
    ignore <- doSomething()
    b <- doSomething()
    c <- process(b) // process(val:Int?) -> Int?
} yield {
    c
}

Intuitively, these two snippets should do the same thing, which is the impetus for enshrining the behavior in a law.

• • • • •

Remembering that the...

In my last post, I finally came out and admitted that all my posts about errors and optionals have been about monads. And to justify this gross act of deception, I posited for-comprehensions, a nifty new syntax in Magical Future Swift that improves how we can work with optionals and arrays—a syntax that only works with monads.

So monads are entities that work with for-comprehensions. But for-comprehensions must work in a sane manner, that is, intuitively. I’ve already gone over two behaviors that are required; they are called the first two monad laws. There is one missing. You’ll be stunned to know it is the third law.

• • • • •

The first law addressed using a for-comprehension with a lifted value. The second law addressed the behavior of comprehensions when nothing was done to the assigned values. One last thing we want to be able to do with comprehensions is nest them.

To see why...