ruby

Extending the Swift language is cool, but be aware of what you are using

Posted on by airspeedvelocity

Features like the @auto_closure keyword in Swift offer a great opportunity to extend the language in ways that might not be possible in other languages. For example, in this article we used it to implement the Ruby ||= operator.

Swift doesn’t yet have a native implementation of unless or until. These are just versions of if or while, but for when the predicate is not true. Obviously you could just stick a ! in front of your if clause, but some programmers prefer the readability of the opposing versions. The implementation of ||= could be rewritten as:

@assignment func ||=<T>(inout lhs: T?, rhs: @auto_closure () -> T) {
    unless(lhs) {
        lhs = rhs()
    }
}

I know, you think, I can implement unless and until myself! What’s nice is you can make them look almost like the native flow control statements, because closure expressions can be outside the parentheses of function calls if they are the last argument.1 Implementing unless seems pretty straightforward:

func unless<L: LogicValue>(pred: L, block: ()->()) {
    if !pred {
        block()
    }
}

// doSomething only if condition is false
unless(condition) {
      doSomething()
}

until is a little trickier, because you need to execute the predicate multiple times as you loop. But @auto_closure can help you out.

func until<L: LogicValue>(pred: @auto_closure ()->L, block: ()->()) {
    while !pred() {
        block()
    }
}

// doSomething until condition becomes true
until(condition) {
    doSomething()
}

Now, the conditional expression passed as the first parameter to until will be automatically wrapped up into a closure expression and can be called each time around the loop. Any variable used in both the parentheses and the block will be captured by both, so altering it in the block will affect the result of the condition (hence the condition can become true over time).

Armed with your new unless and until functions, you write a function to search a collection for the index to the first occurrence that doesn’t match a predicate:2

func findIfNot
  <C: Collection, L: LogicValue>
  (col: C, pred: (C.GeneratorType.Element) -> L)
  -> C.IndexType? {

    var idx = col.startIndex
    until(idx == col.endIndex) {
        unless(pred(col[idx])) { return idx }
        idx = idx.succ()
    }
    return nil
}

let a = [1, 2, 3]
let isOdd = { $0%2 == 1}
// find the first non-odd number
let idx = findIfNot(a, isOdd)

Arguments about SESE and other stylistic preferences aside, this function should do the job. Except instead it generates a compiler error, 'C.IndexType' is not convertible to '()'.

Why? Because the return after the unless is a return from that closure expression between the braces, not a return from the findIfNot function. That unless closure expects no value to be returned, so when you return idx it’s an error. But if you were just blithely using this unless function you found in a library as if it were just like an if statement, you might not realize this and the compiler error may come as a shock.

Now say you instead implemented findIfNot to take in an index into the collection as an inout, and advanced that index to the first non-match, instead of returning a value (and returning the endIndex if every item matches). This is pretty bad code, but here it is:

func findIfNot
  <C: Collection, L: LogicValue>
  (col: C, inout idx: C.IndexType,
  pred: (C.GeneratorType.Element) -> L) {

    until(idx == col.endIndex) {
        unless(pred(col[idx])) { return }
        idx = idx.succ()
    }
}

let a = [1, 2, 3]
let isOdd = { $0%2 == 1}
var idx = a.startIndex 
findIfNot(a, &idx, isOdd)
// idx will not be what you would hope

Now, no compiler error. Instead, this code will fail much more subtly, always returning as if no non-match was found. If we replace the unless with an if, the code will run forever because the until block will return before moving idx forward, and then loop again.

Unit tests should catch this of course. But as a user of built-in-like functions, you should always be aware they aren’t quite the part of the language they might seem. The bugs resulting might not be as obvious as in this case. Also, this is a good argument for using a more “functional“ approach, by writing general algorithms like findIfNot rarely and testing them thoroughly, and then reusing them as much as possible, rather than writing explicit loops.

Should Apple extend Swift to cover this kind of case? Maybe a keyword that causes a closure that doesn’t return a value to be able to pass the return statement out and act on the calling function?3 Until they do, this is definitely a gotcha to be aware of.

  1. Sadly your implementions will always be lacking one feature that if or while have – leaving off the brackets around the predicate. You can’t write unless so it can be used as if pred { } – unless Apple extends “if the last parameter is a closure expression you can have it outside the parens” to be “if there are two parameters and the last is a closure expression, you can leave the parens off the first parameter”. ↩
  2. If you don’t follow what the code here is doing, try reading this introduction to algorithms on collections in Swift. ↩
  3. If I’ve missed something huge here and there’s already a way around this issue, leave a comment! ↩

Swift’s for loops avoid an easy mistake with variable capture

Posted on by airspeedvelocity

This article from a while back points out “the biggest mistake everyone makes with closures” in Ruby, Python, Perl and Javascript.1

Try running this code in Ruby, which counts i up from 1 to 3 creating a closure each time which returns the value of i:

a = []
for i in 1..3
  a.push(lambda { i })
end

for f in a
  print "#{f.call()} "
end

and it prints out the possibly surprising value 3 3 3.

Using more “functional” constructs doesn’t always save you. This Python also prints all 3s:2

a = [lambda: i for i in xrange(1, 4)]
for a in f:
  print f()

The article goes on to suggest some workarounds.

Here is the equivalent in Swift:

var a: Array<()->Int> = []

for i in 1...3 {
  a.append( { i })
}

for f in a {
  println("\(f()) ")
}

and happily, this prints 1 2 3.

Note, this also works with references to objects, so if you subsituted a for over a sequence of objects instead of Ints in the code above, each closure would capture a reference to a different object.

Be careful though, this applies to for loops but not to other loops like while or the C-style for(;;), so:

var i: Int = 0
while(++i <= 3) {
    a.append( { i })
}

for f in a {
    print("\(f()) ")
}

prints out 3 3s.

Why is this? Is this a special hack to make for...in behave less surprisingly? To understand why it does this, you need to realize that this:

for i in 1...3 {
  a.append( { i })
}

is just a shorthand equivalent to writing this code using the source sequence’s generator:

var g = (1...3).generator()
while let i = g.next()
  a.append( { i })
}

The answer to our question lies in the let i =, which declares a fresh variable i for each iteration of the loop, hence if you capture i, it will retain its value at the end of the block. If you use this form of while loop, you’ll get the same results as with the for...in version.

  1. Go here for an epic list of how other languages handle this issue. ↩
  2. The Ruby each will do something similar in version 1.8, though it was altered in 1.9 to behave differently which is somehow more scary. ↩

Implementing some Ruby builtins in Swift

Posted on by airspeedvelocity

Type 1. into irb and hit tab, and it’ll ask you if you want to see all 105 possibilities. Try it with [ ] and you’ll be offered 155. Ruby comes with a lot of built-in methods on its default types.

It’s debatable how useful all of these are. The idiom in Swift seems much more to be like in the C++ STL, where there are algorithms that operate on collections, rather than collections having methods that operate on themselves. To see more about this, read this article on writing algorithms against collections.

But for the sake of looking at a few Swift language features, let’s implement some of the Ruby popular ones. Maybe they’d be useful making a Ruby refugee feel at home.

First off, the Int loops. Lots of “hey look, ruby is cool” intros kick off with this one:

10.times do |i|
   "ruby is cool!"
end

This is pretty easy to add to the Swift Int using an extension:

extension Int {
    func times(f: () -> () ) {
        for _ in 0..self {
            f()
        }
    }
}

10.times { "swift is cool too!" }

Note the _ instead of a variable in the for, because the value isn’t actually needed.

Next, two for alternatives, upto and downto:

1.upto(3) {|i| print "#{i}.. "} # prints 1.. 2.. 3..
3.downto(1) {|i| print "#{i}.. "} # prints 3.. 2.. 1..

in Swift would be:

extension Int {
    func upto(n: Int, f: (Int) -> () ) {
        for i in self...n {
            f(i)
        }
    }
    func downto(n: Int, f: (Int) -> () ) {
        for i in reverse(n...self) {
            f(i)
        }
    }
}

Note the use of the inclusive ... this time, unlike with times which used the convention of a zero base up to but not including n so needed non-inclusive .., because this time we want to start at self and count inclusively to n. Humorously, Ruby also has inclusive and exclusive ranges but .. and ... are the opposite way around.

For downto, the range is wrapped in a reverse in order to count backwards.

Next, some extensions to array, in a similar vein to map or reduce.

Ruby’s each is like map, but doesn’t generate any return value:

extension Array {
    func each(f: (Element) -> ()) {
        for e in self {
            f(e)
        }
    }
}

Element is a Type Property representing the type of value the Array contains, to this function works generically for type contained by array.

Ruby’s reverse_each does the same but in the opposite direction:

extension Array {
    func each(f: (Element) -> ()) {
        for e in Swift.reverse(self) {
            f(e)
        }
    }
}

Again, we use reverse to go backwards through the array. Wait, you might think, isn’t it inefficient to reverse the array just to iterate over it? But that’s not what reverse does – instead it generates a lazy collection that serves up the values in reverse order.

Note, we have to prefix it Swift.reverse to disambiguate it from the Array member function reverse – which would result in creating a whole new array in reversed order, if we used it.

Ruby’s delete_if is the opposite of Swift’s filter – it takes a discriminator function and returns any elements that don’t match. We could easily just implement it from scratch with a for loop, but instead let’s try and implement it by re-using filter.

One way to do this is to first create what’s called a “decorator”. Decorators are functions that take other functions, and return a new function that has changed the behaviour of the original function in some useful way.

What we want is a decorator that takes a function that returns a boolean, and then returns the opposite of that. Here it is:

// function that takes a function, f, that takes an element
// and returns a bool, and returns a function that applies f
// then returns the opposite
func not_f<T>(f: (T)->Bool) -> (T)->Bool {
    // this returns a closure that captures f
    return { !f($0) }
}

If you’re a bit hazy on closures and variable capture, read this.

Armed with not_f, we can define delete_if:

extension Array {
    func delete_if(f: (Element) -> Bool) -> Element[] {
        return self.filter(not_f(f))
    }
}

Finally, Ruby’s equivalent of filter is called select. It’s identical, it’s just called by a different name. Is there some way we could alias filter if we wanted?

Yup, like this:

extension Array {
    var select: ((Element) -> Bool) -> Element[] { 
        return Array.filter(self) 
    }
}

You can now use select in exactly the same way you use filter. This is quite a silly thing to do, but it does demonstrate a couple of language features: read-only computed properties that return closures, and references to member functions.

Read-only computed properties are used like regular properties i.e. can be accessed using the dot syntax, but behave like functions that take no arguments and return a value. In this case we have defined a property select that returns a function when you call it. We’re just returning an existing member function (more on that next) but you could have more complex logic that created and returned different kinds of closures.

The reason it’s nice to implement these as computed properties is you don’t need to use a () after the property name. This means if you want to compute a function for someone to use, they can use it like this: x.computedfun(). If computedfun was itself a function, you’d have to write this: x.computedfun()(), which looks odd. Other than that, they behave just like functions that return functions.

So what is select actually returning? To understand that, you need need to realize you can reference a classes’ member functions. See the following code:

class MyClass {
    let n: Int

    init(_ i: Int) { n = i }

    func multiply(i: Int) { 
        println("n: \(n) * i: \(i) = \(n*i)")
    }

    func add(i: Int) { 
        println("n: \(n) + i: \(i) = \(n*i)")
    }
}

let a = MyClass(2)
let b = MyClass(5)

// prints "n: 2 * i: 10 = 20"
a.multiply(10)

// prints "n: 5 + i: 10 = 50"
b.add(10)

// this takes a reference to the member 
// function multiply of MyClass
var memfunref = MyClass.multiply

// you can't use memfunref directly.
// you have to apply an instance of
// MyClass to it:
var instancefunref = memfunref(a)

// now you can call it, and it's
// like calling a.multiply, so
// this prints "n: 2 * i: 10 = 20" 
instancefunref(10)

// MyClass.add has the same type as
// MyClass.multiply, they're both (Int)->(),
// so you can assign it to memfunref too:
memfunref = MyClass.add

// and apply a different instance of MyClass
instancefunref = memfunref(b)

// this prints "n: 5 + i: 10 = 50"
instancefunref(10)

// or you can skip the instancefunref step
// prints "n: 5 + i: 10 = 50" again
memfunref(b)(10)

Now we can see what that computed property is doing. It’s returning the member function filter of Array, then applying self to it, and returning that. The caller then can call the returned function () and it runs filter against the object they fetched it from. Like I said, bit silly, but it demonstrates a feature that could probably be put to better use in other cases.

If you liked this post, this one is also about implementing Ruby features in Swift, in this case implementing the ||= operator using the @auto_closure Swift feature.

Implementing Ruby’s ||= operator in Swift using @autoclosure

Posted on by airspeedvelocity

edit: this has been updated for Swift as of Xcode 6.1 (Swift 1.1)

A common idiom in Ruby is to assign a value to a variable only if that variable isn’t already set, using the ||= operator:

s ||= "default value"

Swift doesn’t provide such an operator out of the box, but using some of the features of the language, it’s possible to implement one.

Simple first implementation

First let’s try implementing it just for string types. We need to define the operator itself first:

infix operator ||= {
    associativity right
    precedence 90
    assignment
}

And then implement it with a function:

func ||=(inout lhs: String?, rhs: String) {
    if(lhs == nil) {
        lhs = rhs
    }
}

Note the use of the assignment attribute on the operator definition, and the inout parameter on the left-hand side, which is the variable being assigned to.

This works. If you try the following

var s: String?
s ||= "first assignment"
s ||= "second assignment"

the second assignment will have no effect on s – it will keep the value “first assignment”.

Using generics to apply to any type

What about implementing this with generics, so it will work not just for String but for any type? That’s pretty simple:

func ||=<T>(inout lhs: T?, rhs: T) {
    if(lhs == nil) {
        lhs = rhs
    }
}

Now you can use our ||= on any type optional type – String?, Int?, or any user-defined class.

Using autoclosure to avoid unncessary evaluation

Our ||= still doesn’t quite match the Ruby version. If the value on the left-hand side is already set, the statement on the right-hand side is never executed. This is important if, for example, the right-hand side were a function with other side-effects, or an expensive computation.

But by default in Swift, any statement passed to a parameter is fully executed first. To replicate the Ruby functionality, we have to use an attribute in Swift called autoclosure. This is used like this:

func ||=<T>(inout lhs: T?, rhs: @autoclosure () -> T) {
    if(lhs == nil) {
        lhs = rhs()
    }
}

What autoclosure does is wrap the arguments suppled in a closure, for later execution. Then, if they aren’t needed, they are never executed. If they are needed (in this case, because lhs is nil), the closure can be called (note the new type for rhs, and the parenthesis after rhs, indicating it is now calling a function).

To check this works, try the following, which should only print “I’ve been run” once to the console:

func printlnWhenRun() -> Int {
    println("I've been run")
    return 0
}
var i: Int?
i ||= printlnWhenRun()
i ||= printlnWhenRun()

Implementing for Boolean values

This works great for optional types, but what about the more conventional behaviour, a compound logical-OR-and-assign operator for boolean values?

Despite listing it in the Expressions precedence section of the language reference, this doesn’t appear to be implemented in Swift natively.

edit: it’s now been removed from the precedence section. You can still declare it as below though.

No problem though, we can just implement it ourselves. Here it is:

func ||=<T: BooleanType>(inout lhs: T, rhs: @autoclosure () -> T) {
    if(!lhs) {
        lhs = rhs()
    }
}

Note the BooleanType type constraint after the type parameter. This is necessary because we need to guarantee that you can pass whatever type is used into the if statement. This wasn’t necessary with the other version because it was the optional qualifier supplying this ability.1

But doesn’t this clash with the other definition? Nope. A combination of the type constraint on the logical version, and the presence of the optional parameter on the optional-assignment version, means the possible uses of these two functions are entirely disjoint, and the Swift compiler will pick the right one for you. Even a Bool? type will go to the optional-assignment version.2

Using lazy properties instead of ||=

Having done all of this, you could argue ||= isn’t all that useful in Swift because of different feature, lazy properties. These are properties of a class or struct that are only initialized for the first time when they are used – in much the same way as Ruby devs use ||=. Below is some code showing this in action:

class MyClass {
    lazy var complexThing = CreateComplexThing()
}
var c = MyClass()
// ... maybe some time later
var thing = c.complexThing  // CreateComplexThing() runs now

Obviously this only applies when your property is part of a class, not when you’re declaring a variable in a function, so maybe there’s still a place for ||=. But if not, at least we learned something implementing it.

  1. And there’s no need to constrain to objects with the ability to assign to each other – they all have that ability. There’s no “Assignable” protocol. Be nice if there were – that would imply you could overload “=”. But this ain’t C++. ↩
  2. It is possible to write two generic functions that overlap in their inputs, in which case you will get an “use of unresolved identifier” error from the compiler when you call the function (note, not when you define the overlapping function, which is a break from other features of generics when you get a compiler error at the time of definition rather than use). ↩

Using Any to Store Numbers in Swift

Posted on by airspeedvelocity

In the last post we implemented an accumulator using generics, so it could handle either integers or floating point types.

But how about handling both in the same accumulator? In Paul Graham’s guidelines for submitting an accumulator, he says it needs to work

for any numeric type – i.e. can take both ints and floats and returns functions that can take both ints and floats. (It is not enough simply to convert all input to floats. An accumulator that has only seen integers must return integers.)

He then gives some example usage: 1

E.g. if after the example, you added the following code (in a made-up language):
x = foo(1);
x(5);
foo(3);
print x(2.3)
It should print 8.3.

But if you try to do this with our generics implementation, you will get a error when you pass in the final number. “Cannot convert the expression’s type ‘Int’ to type ‘Int’”, the compiler will say, which is a little confusingly worded given it’s a Double that can’t be converted, but what it means is it can’t convert what you passed to it’s Int parameter into an Int.

So I guess our example still isn’t valid for submission. What behaviour do we need? In Ruby, you can do the following:

irb> n = 1
 => 1
2.1.0 :002 > n.class
 => Fixnum
2.1.0 :003 > n += 2.2
 => 3.2
2.1.0 :005 > n.class
 => Float

The value n silently gets upgraded to a float. How can we do this in Swift? Well, there is an Any type that can hold any kind of type. But it’s not as easy as that. Just trying the following:

  func foo(var n: Any) -> (Any) -> Any {
    return { n += $0; return n }
  }

gets you the familiar compiler error about there being no overloaded += operator. But unlike when we had this problem with generics, this can’t be fixed with type constraints. Any doesn’t implement +=.2 In fact, Any doesn’t let you do much of anything except store a value and pass it around. If you want to maniuplate what’s inside, you must use a switch statement:

let a: Any = 1
switch a {
case let i as Int:
  // do appropriate logic when it's an Int
...
}

If we revisit our incf implementation, but adapt it to take and return Any, and upgrade an Int to Double by switching to identify them, we get the following monstrocity:

func incf(inout lhs: Any, rhs: Any) -> Any {
    switch lhs {
    case let i as Int:
        switch rhs {
        case let j as Int:
            lhs = i + j
        case let d as Double:
            lhs = Double(i) + d
        default:
            // what to do here?
        }
    case let d as Double:
        switch rhs {
        case let e as Double:
            lhs = d + e
        case let i as Int:
            lhs = d + Double(i)
        default:
            // what to do here?
        }
    default:
            // what to do here?
    }
    return lhs
}

What to put in for those default cases, where one of the types isn’t supported. Maybe throw an exception? Hahaha only kidding, Swift doesn’t have exceptions.3 The Swift way of handling this would be to allow incf to return a nil type.4 Users of foo then have to account for the possibility of an error. Let’s do that, and add an implementation of foo with our new incf:

func incf(inout lhs: Any, rhs: Any) -> Any? {
    switch lhs {
    case let i as Int:
        switch rhs {
        case let j as Int:
            lhs = i + j
        case let d as Double:
            lhs = Double(i) + d
        default:
            lhs = nil
        }
    case let d as Double:
        switch rhs {
        case let e as Double:
            lhs = d + e
        case let i as Int:
            lhs = d + Double(i)
        default:
            lhs = nil
        }
    default:
        lhs = nil
    }
    return lhs
}

func foo(var n: Any) -> (Any) -> Any? {
    return { incf(&n, $0) }
}

There are many flaws in this approach, but it does at least work with the example above now – pass an Int and then a Double and you’ll get a Double.

Pass a Float in though and you get back a nil. But adding Float to the already nasty switch statement will make it even nastier. If we wanted to extend incf to cover even more types (maybe numeric classes like a Rational or Decimal) it gets even worse. And if we want to implement a decrement function we’d have to replicate the whole statement.

There’s one more way to write the switch statement. Swift’s pattern matching can operate on multiple values together, giving us the following alternative to having to nest multiple switch statements:

func incf(inout lhs: Any, rhs: Any) -> Any? {
    switch (lhs,rhs) {
    case let (i as Int, j as Int):
        lhs = i + j
    case let (d as Double, e as Double):
        lhs = d + e
    case let (i as Int, d as Double):
        lhs = Double(i) + d
    case let (d as Double, i as Int):
        lhs = Double(i) + d
    default:
        lhs = nil
    }
    return lhs
}

Unfortunately, while this code is a little more succinct, and possibly less error-prone, it still suffers from the same problems if you tried to extend it to more types.

The next post will be about ditching Any in favor of a more type-safe approach to this problem.

  1. Note, he calls foo a second time in his example. Presumably he got a lot of duff submissions where people were using global variables to accumulate. ↩
  2. And before you try it, no, you can’t extend Any to try and implement +=. Or anything else for that matter, it’s unextendable. ↩
  3. This is a good example of how removing exceptions forces you to find a perfectly valid alternative in many cases. Exceptions were always discouraged in Objective-C except for truly exceptional circumstances, Swift took this one step further and did away with them entirely. ↩
  4. If you think the right thing to do is not add the number, you’ll hit a different problem. That means the default action should do nothing, but Swift insists you have some code there. So you have to write something that doesn’t have any effect. Feel free to get creative. No, I’m afraid a comment saying “do nothing” doesn’t count as something. ↩

An Accumulator in Swift, Part 2 – Using Generics

Posted on by airspeedvelocity

In Part 1 of this post, we wrote an implementation of Paul Graham’s accumulator problem in Swift. Here’s one of the versions:

func foo(var n: Int) -> (Int) -> Int {
  return { n += $0; return n }
}

This looks pretty similar to the Ruby version he gives:

def foo (n)
  lambda {|i| n += i }
end

Except there’s a problem. On his page of guidelines for submitting an example in a new language1 he points out it needs to:

[work] for any numeric type – i.e. can take both ints and floats and returns functions that can take both ints and floats. (It is not enough simply to convert all input to floats. An accumulator that has only seen integers must return integers.)2

In Ruby, this isn’t an issue because of the duck typing. But in Swift, if you try to pass a Float to foo, you’ll get an error. We’re going to have to use another feature to fix this – generics.3

First let’s try implementing incf using generics, so it can take an Int or a Float. We do this by defining a type parameter T in angle brackets after the function name, and then using that instead of the explicit Ints:

func foo<T>(var n: T) -> (T) -> T {
  return { n += $0; return n }
}

Oops, more compiler errors. “Could not find an overload for ‘+=’ that accepts the supplied arguments” again.

This is because not all objects have a += operator, so if you tried to use it with one of those, it wouldn’t work. Unlike in C++ templates, where you wouldn’t get a compiler error4 unless you tried to use incf with a type that was missing a +=, Swift requires you to restrict your types up-front.

The way you ensure a type will support the necessary member functions is by using Type Constraints. These are protocols you append to your generic type. For example, if you wanted to write a generic less_than function, you could use the Comparable type:

func less_than<T: Comparable>(lhs: T, rhs: T) -> Bool {
    return lhs < rhs
}

Only classes that implement the Comparable protocol can be used with the less_than function, and because they impelement this protocol they’re guaranteed to have a < operator.

The Swift standard library only defines 3 protols so far – Equatable, Comparable and Printable.5 They don't cover what we need, so we'll define our own. Let's call it, uhmm, Addable.

protocol Addable {
    @assignment func += (inout left: Self, right: Self)
}

Then, we need to declare that Int and Float support Addable by extending them with the new protocol:

  extension Int: Addable { }
  extension Float: Addable { }

Finally, let's try our generic function with the new constraint:

func foo<T: Addable>(var n: T) -> (T) -> T {
  return { n += $0; return n }
}

Now, if you pass in a Float to foo, it works.6. In fact, if you tag any type that implements += it will work for that type too. Try it with String.

Anyway, with this requirement covered, hopefully we can add Swift to the pantheon of powerful languages. Maybe one day they'll take new submissions to the page!

  1. These pages tell a story. First he was all hey guys, let’s get all the examples, this is cool! Then he’s like, no you numbskulls, read the problem, that’s not what it says! Eventually he gives up and tells people to stop emailing him. ↩
  2. Strictly speaking what we’ll implement still doesn’t cover this requirement, because the quote and the example following it implies it needs to be able to switch dynamically between integers and floating point halfway through. Read the next part for a solution to this. ↩
  3. I love generics. But then the first language they taught me in college was Ada, and after that I spent years in the C++ mines, so it’s not surprising. ↩
  4. The compiler error will be about 10 lines long and will fill you with hopeless despair. Concepts, something similar to Swift’s protocol constraints, didn’t make it into C++11. ↩
  5. They don't define Assignable. I guess that's considered so fundamental you can take it as a given. Presumably they're going to add a lot more standard protocols to the library over time, so keep an eye on that page. There are several more implemented but not yet documented – to see them, type import Swift into playground, and command-click it. ↩
  6. I was pretty amazed when it did the first time I tried this. ↩

An Accumulator in Swift

Posted on by airspeedvelocity

In an appendix to his article Revenge of the Nerds, Paul Graham suggests a problem to solve in a programming language to see how “powerful” that language is.1

The problem: Write a function foo that takes a number n and returns a function that takes a number i, and returns n incremented by i.

Also note,

(That’s incremented by, not plus. An accumulator has to accumulate.)

Solving this problem is one of the first things I try when learning a new language. This article will implement various versions this function in Swift, as a way to explore some of Swift’s features.

Here’s a first attempt. It’s very similar to the makeIncremetor function in the Closure section of the Apple Swift book, except adapted to match Graham’s definition of the problem:2

func foo(n: Int) -> (Int) -> Int {
  var acc = n
  func inc(i: Int) -> Int {
    acc += i
    return acc
  }
  return inc
}

Read that first line defining foo as: it takes a parameter, n, and returns a function, which itself takes an Int as a parameter and returns an Int.3

That returned function is a closure – a self-contained combination of a function and an environment of variables (in this case, just one, acc). Each time you then call that returned function, it adds the value i you pass in to acc to keep a running total, and then returns the latest total.

In case you’re not familiar with closures, here’s a short explanation of what’s happening.4 When declared, the function inc “captures” the outer variable acc, so instead of acc being destroyed when it falls out of scope, it sticks around and continues to be useable by the inc function. Note that if you call foo again, it creates a brand new inc function/acc variable pairing, starting from whatever n you just passed in. Think of this as similar to creating a new instance of a class with a member variable acc, initialized with n.

So, people have been enjoying comparing swift to other languages. I like Ruby, so let’s take the Ruby example from Graham’s list of canonical solutions to his problem.

def foo (n)
  lambda {|i| n += i }
end

Well that’s a lot more compact!5 Let’s look at why, and get our Swift example closer.

The Ruby example just captures and uses the input parameter n for its state variable. We can do this in Swift too, with the addition of the var keyword in front to allow it to vary (without those changes affecting the caller’s passed-in variable):

func foo(var n: Int) -> (Int) -> Int {
  func inc(i: Int) -> Int {
    n += i
    return n
  }
  return inc
}

Next, the inner function is anonymous, and returned directly. We can do that in Swift too. Unlike in Ruby, we don’t need to use a lambda keyword to declare an anonymous function:

func foo(var n: Int) -> (Int) -> Int {
  return { (i: Int) -> Int in
    n += i
    return n
  }
}

Now let’s look at all those type declarations cluttering up the place. Ruby doesn’t have them because it is duck typed. Swift on the other hand is strongly typed.6 But there is hope – some of them can be eliminated by Swift’s type inference. In the inner function, we already know the types of everything being passed in or returned, so we can leave them off and the compiler infers them from the context:

func foo(var n: Int) -> (Int) -> Int {
  return { i in n += i; return n }
}

Do we still need the declaration of i? If the types can be deduced, you can use $0, $1 etc for the arguments, and skip the in.

func foo(var n: Int) -> (Int) -> Int {
  return { n += $0; return n }
}

Finally, so long as a closure is just a single expression, you don’t need an explicit return – the result of the expression is automatically returned. This leaves us with something very similar to Ruby, where the last statement is always returned (in Ruby’s case, even with multi-line functions).

func foo(var n: Int) -> (Int) -> Int {
  return { n += $0 }
}

Except oops, no, that last one won’t compile. “Could not find an overload for ‘+=’ that accepts the supplied arguments” it says. That’s a little confusing, because the “argument” in question is actually the return type. In Swift, += doesn’t return a value7 (unlike in Ruby where almost every statement has a value8 and can be used on the right-hand side, even an if statement).

If you were thinking, I know, let’s override += to return a value, nope Swift won’t let you do that.9 Also, you’re the reason I hate other people’s code. To get inspiration for an alternative function, let’s look at the lisp example from the canonical list:

(defun foo (n)
  (lambda (i) (incf n i)))

And here is an implementation of that function:

func incf(inout lhs: Int, rhs: Int) -> Int {
  lhs += rhs
  return lhs
}

Note the use of the inout keyword to indicate that the changes made to this parameter affect the variable passed in by the caller, unlike with var.

Since our new function returns a result, we can now use it to implement a single-expression closure:10

func foo(var n: Int) -> (Int) -> Int {
  return { incf(&n, $0) }
}

Swift requires you to put an & in front variable when passing in an inout parameter, which is nice as it means you can’t accidentally miss the possibility of side-effects.

That’s probably as far as we can go. It’s pretty similar to the Ruby version at this point. Except… we didn’t quite solve the stated problem. To find out why, read on to Part 2 of this article.

  1. If you take issue with this as a measure of language power, take it up with Mr Graham.#160;↩
  2. If you’re eyeing foo suspiciously, and wondering why it isn’t called, say, makeAccumulator, I agree with you. ↩
  3. I’m not wild about the Swift syntax for type definitions of functions returned from functions. I know it’s completely unambiguous if you read it from left to right but it makes me nervous when I look at it. I don’t have any better proposals, either. ↩
  4. Those who are familiar – please be gentle with me and my explanation! ↩
  5. Note I said compact, not neater or cleaner or more expressive. But I happen to think it’s those things too. ↩
  6. Terms like strong or duck typing are not rigorously defined, but people can get very emotional about it when they think they’re being used incorrectly. Please email Casey. ↩
  7. I do wonder why they decided to not have assignment return the value of the left-hand side. Seems like this is a legit use case. I guess maybe they they thought it was too side-effecty to change a value while also using it? But if you’re going to do that, go all the way and ban ++i from being used on the right-hand side of expressions – but that would probably lead to the C guys assaulting the castle with torches and pitchforks. ↩
  8. That’s right, almost everything. Not everything. Grrr. Though, otherwise, I really like this language feature. ↩
  9. Interestingly, it will allow you define += return a value when you write it for your own classes. This is probably not a good idea. ↩
  10. Yes I’m aware writing a two-line function just to compact less code elsewhere is a bit silly, but give me a break, we’re just experimenting here. Plus I think the lisp “build up the language to meet your problem” thing is a nice idea. ↩