

Immutable Enumeration in Swift - tel
http://tel.github.io/2014/07/30/immutable_enumeration_in_swift/

======
lobster_johnson
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.

~~~
tel
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).

~~~
lobster_johnson
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.

~~~
tel
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.

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

~~~
lobster_johnson
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.

~~~
tel
Well said!

