Arguments for explicit block delimiters in programming languages

February 28, 2014

Suppose that you have a language where indentation levels are significant; either they explicitly delimit blocks (as in Python) or mismatched indentation is an error. I maintain that this is a good thing in a language in general because it makes human semantics match computer semantics. One of the big questions about such a language is whether it should have explicit block delimiters or rely purely on indentation levels.

A lot of people will likely argue for the Python approach of implicit delimiters, ie that blocks are created and exited by indentation alone. Although I like Python, I actually tilt towards at least allowing and perhaps requiring explicit delimiters. I see two advantages to explicit delimiters.

First, explicit delimiters are in fact explicit. They provide confirmation that you did indeed intend to create a new block or to exit one and that you didn't just accidentally get the indentation wrong on a line. This is going to be especially important in a language where you can create new block levels at any time (not merely after a language construct such as if or while) and such blocks can have semantic meaning such as containing block-local variables.

(Note that Python is not such a language. Unlike C, where you can create a block anywhere just by dropping in { and }, Python blocks can only be started after specific statements.)

Without explicit delimiters there are a number of ways for block errors to creep in, even in languages like Python. I feel that the explicitness of block delimiters is definitely suited for languages that are designed with an eye towards software engineering pragmatics in the line of Go's design; in such languages you'd rather make the programmers do a bit of extra work than have an error slip by.

Second, explicit delimiters enable you have to have blocks that are smaller than a single line and to have several such blocks on one line. Consider:

if (acheck()) { b = 10; fred(); } else { b = 30; barney(); }

You can't do this without explicit block delimiters. Of course, some people will probably say that you shouldn't do this even with block delimiters; if you agree, this is not a very compelling point and may in fact be an argument against explicit block delimiters.

I personally like such compact blocks, in part because of issues like anonymous functions (or real lambdas) where you may well want to put several short statements on a single line and in fact explicitly package them up as a block for the lambda.

(I believe that lacking a good syntax for such inline code blocks is one reason that Python has such a limited lambda operator.)

Comments on this page:

Or, as I understood it, not lacking so much as not wanting. I.e. the limited lambda is considered an acceptable trade-off for not having to introduce the things that a more powerful lambda would require. At least that is how Guido has sounded to me when opining on the issue.

If you want a block, use a partial! This article reminds me of why lambas seem so out of place...

Written on 28 February 2014.
« PCI slot based device names are not necessarily stable
Yet another problem with configuration by running commands »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 28 00:39:52 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.