Saturday, July 13, 2013

Statements vs Expressions

Many programming languages have separate concepts for statements and expressions. I like to think of the distinction between them as follows:

Statement: What code does

Expression: What code is

I want to clarify that in this post I will deliberately use the term "statement" very broadly to refer to anything that is not an expression or type declaration. If you disagree with this terminology then I welcome suggestions for an alternative name.

The distinction between statements and expressions closely parallels the difference between imperative languages and functional languages:

Imperative: A language that emphasizes statements

Functional: A language that emphasizes expressions

C lies at one end of the spectrum, relying heavily on statements to accomplish everything. The classic example is iterating over an array:

In Haskell, "statements" are actually nested expressions, and sequencing statements just builds larger and larger expressions.

This statement-as-expression paradigm promotes consistency and prevents arbitrary language limitations, such as Python's restriction of lambdas to single statements. In Haskell, you cannot limit the number of statements a term uses any more than you can limit the number of sub-expressions.

Monads

do notation works for more than just IO. Any type that implements the Monad class can be "sequenced" in statement form, as long as it supports the following two operations:

Semantics

Notice that we can evaluate these Maybe "statements" without invoking any sort of abstract machine. When everything is an expression, everything is simple to evaluate and does not require understanding or invoking an execution model.

In fact, the distinction between statements and expressions also closely parallels another important divide: the difference between operational semantics and denotational semantics.

Operational semantics: Translates code to abstract machine statements

Denotational semantics: Translates code to mathematical expressions

Haskell teaches you to think denotationally in terms of expressions and their meanings instead of statements and an abstract machine. This is why Haskell makes you a better programmer: you separate your mental model from the underlying execution model, so you can more easily identify common patterns between diverse programming languages and problem domains.

But one day you discover that you want jumps. Like, imagine you walk around the tree and calculate the product of all its nodes. Apparently, when you encounter a zero, you can return zero right away.

And that's where statement-oriented languages and operational semantics of an abstract machine perform better than expression-oriented languages and denotational semantics: in the former case, jumps are extremely straightforward, clear, and intuitive. But try to model them in a lambda-calculus! Introduce a denotational semantics for them! Well, okay, that's not impossible, and people figured it out by the middle of the seventies — you need continuations. But the result is pretty gross. CPS-transformed programs look awful, with all that plumbing lying in plain sight, and continuations themselves are kinda confusing.

Sure, with right syntactic sugar you can do this. But reasoning about them is still not pleasant, especially in a lazy language — jumps mess up evaluation order, and there is little you can do about this.

Great post. I wrote about statements vs expressions in a blog post a while back too, but I think your's was much more illustrative. If you're interested in an F# vs C# perspective on this you can find my post here: http://richardminerich.com/2012/07/functional-programming-is-dead-long-live-expression-oriented-programming/

I don't know how WordPress works, but Blogger provides really nice statistics that you can use to track how many people visit your site and where they come from. This helps you know how broad your readership is and I also use these kinds of statistics to hone my writing by studying which of my posts are well received and get reshared frequently.

Also, when you first start out it helps to pick a specific social network that is appropriate for your blog and submit posts there a few times. Having a thick skin helps, too. :) For example, I began by tailoring my posts to /r/Haskell and regularly submitting there while listening to their suggestions and criticisms (mostly criticisms) in the comments to improve the quality of my posts. That's how I slowly grew a reader base and developed a more personal connection with people who read my blog.

Once you build an active and personal connection with your readers like that it greatly improves the joy of blogging and then you don't feel like you are talking into an empty void. Instead it feels like chatting in public with friends.

Nice post, but I don't agree with your analogy/distinction between operational semantics vs denotational semantics. For example, I don't think that this rule from operational semantics of simply typed lambda-calculus has anything to do with statements or imperative programming:

It merely says how can we evaluate an _expression_ from subexpressions. Of course, operational semantics for imperative languages involve some sort of abstract machinery most of the time. But equally you can build denotational semantics for imperative languages: you can interpret statements as functions on the memory stores and then ';' operator as composition of functions.