Time vs Space

As I work more with functional languages, especially lazy functional languages, I'm starting to come to a deep understanding of the ways in which data and computation are interchangeable. I alluded to this earlier, in a blog post about perlisisms, and whether the distinction between data and function has any meaning for lazy languages.

I just came across a more detailed discussion of this concept by James Coplien, written in 1998.

(The rest of this post is going to be much less accessible than that article, because I'm too tired and rushed to write clearly right now. If anyone wants me to elaborate on what comes below, post a comment and ask.)

Lazy evaluation means that passing a value is the same as passing a computation. Note that by "passing a computation", I mean passing a live squirming active thing, not just a dried-out function pointer or closure.

Curried functions mean that multi-argument function calls become structures with multiple pieces -- rather than being one atomic all-or-nothing invocation.

I don't yet understand this train of thought well enough to know why haskell needs to distinguish between "data" types and functions. Perhaps the only reason is so that data types can be pattern-matched, whereas functions are opaque. It would be fascinating if that were the only reason for the distinction. It begs the question of why functions have to be opaque. Suppose they weren't: what would pattern matching on function values mean? what kinds of patterns would you match against?

Pattern matching against data is used for two reasons: distinguishing between variants of a data type (e.g. null versus not-null), and pulling out member variables (e.g. the actual value of the not-null variant). Applying this kind of thing to functions makes me think of objects implemented as closures. This technique lets you take an opaque function value and call arbitrary methods on it, like an object. Obviously these methods could allow you to discriminate between variants as well as request member variables -- just like objects an any regular OO language.

Haskell lets you blur the distinction between computation and state. What if it also let you blur the distinction between functions and data? Usually when you simplify a programming language, it leads to greater understanding and greater expressiveness. What would this lead to?

Posted on June 9, 2003 06:20 PM
More languages articles