Very interesting. I'm surprised that Swift is already expressive enough to support constructs like this.

Swift is young enough that it hasn't landed on a particular philosophy yet, and I wonder if it will bend toward ML or more in the direction of Go. For example, protocols and functions currently seem somewhat contradictory; getting the Unicode-compliant length of a string is a function, countElements, not a method, for example.

The fact that Swift is both OO and functional (with generics to boot) means there is an inherent conflict in the language that could lead to multiple styles of using it becoming popular. Witness Ruby's stylistic transformation as it became popular and started trends that now make the old standard library seem antiquated by comparison. Or C++'s transformation through the STL. Or Python's engagement with functional programming (which never really was able to transform it away from its OO origins).

By comparison, Go is simple and inexpressive, so that it's practically impossible to break style; indeed that seems to be core to Go's philosophy.

I really would like to practice merging FP and OO together meaningfully in a language. So far, I've been enjoying this in Haskell and I think Swift provides another opportunity.

I'm a firm believer that OO and FP are more like two sides of the same coin than real competing interests (in particular, initial v final data types).

Unfortunately, I think the strong association of mutability and OO is a detriment and Swift follows it (probably for ObjC compatibility).

Agreed. I also wish their OO approach would be more like Go or even Ceylon; as it stands, it looks like they took a reasonable base language and merely bolted ObjC's class model onto it, with no unifying philosophy about the language as a whole.

Yeah, it feels complete but unintegrated. I know a lot of the outstanding Swift tickets are around better integration, but there's a wide gulf.

I ran screaming from this article. I understood virtually nothing about it.

The article plays with the idea of introducing "uncons" to the language, which corresponds to a Haskell expression (simplified; also possible in other ML languages as well as Erlang) such as this:

    x:xs = someList

This means: Assign the head (ie. the first element) of someList to the variable x, and the remaining elements to the variable xs.

In Haskell, ": "is the list concatenation operator. (So if you think about it, the left hand side and the right hand side are in fact together an equation.) The ":" operator is often called "cons", and it's really a function which takes a head and a tail and returns a new list; hence, "uncons" is the reverse, breaking apart a list into an element and a new list.

This is useful because when processing sequences of stuff, you often want to look at the first element, do something, and the process the rest. A linked list is per definition a head and a tail, whereas other structures such as arrays and even files can be adapted into this abstraction. Even a virtual sequence such as a random generator can adopt this protocol: The head of the random generator is the next random number; the tail is the new state of the generator.

The article then tries to formulate this uncons operation as a Swift protocol, and talks about ways to leverage it for different types and functional constructs. Those constructs (such as fold) are the basic tools of functional programming, but will admittedly be completely unfamiliar to someone who hasn't touched the topic before.

Well said!

I freely admit that I'm not exactly writing for all audiences, but I'd love to know what gave you trouble. I'm just learning Swift myself and applying some (fairly weird) techniques to it in order to get some give from its (very nice) immutable data structures.

I ended up writing this as a little background for another post I was more earnestly working on that implements a lazy, non-deterministic parser combinator library. That one might be more interesting and I'll try to write it so that you can get by without too much knowledge from this post.

It's not so much the Swift, which I've been learning just from an application development perspective. It's that your comp sci kung fu is obviously much stronger than mine, and coupled with the fact that you're even at the point that you're dealing with Swift compiler bugs added to my fear.

The article is certainly well-written, though.

The Swift compiler bugs mostly have to do with the fact that it segfaults when it encounters recursive `enum`s and `struct`s. I wrote what the code ought to look like alongside the "fixed" bits, so perhaps that'll help make it more clear.

And as far as the compsci kung fu goes—I'll admit this probably isn't the best intro to it all. It's nice that Swift gives leverage to pull these kinds of gymnastics off, though.