Rhapsody in Blue: the Colour of BGGA Closures

Background

• Many people claim that the various Java closures proposals are difficult to read.
• Others claim that Java is a blue-collar language and should stay true to its roots circa 1997.
  
• The BGGA proposal refers to Tennent's Correspondence Principle which gives return (and other keywords) a different meaning than their use in anonymous inner classes.
• This article and many others represent the syntax in simple black text. Some claim that cut-and-pasting legacy code (anonymous inner classes) into new BGGA closures would introduce errors.
  

The Idea

• Java may or may not be a blue-collar language, but modern Java IDEs are certainly not blue-collar. They are very sophisticated.
  
• This post by Weiqi Gao is one of the few to show BGGA as we might eventually see them: in colour.
• Syntax highlighting make BGGA closures easier to read, and may mitigate the tension between Tennent's Correspondence Principle and anonymous inner classes.
• Read on for details and decide for yourself. Note that the use of colour is completely arbitrary. I don't know if it is possible (or timely) in an IDE (but it seems reasonable).

Note: Code examples use the latest BGGA prototype, explained in this post by Zdeněk Troníček. The use of "==>" versus "=>" is intentional.

An Example

Here is a contrived example, simply intended to illustrate the idea (this is not my submission for the Turing award).

Click on the screenshots for a better image.

This method uses a BGGA closure to build a list of Employees from a list of Strings within a transaction. With the latest version of the BGGA prototype, the ==> symbol means that the closure is unrestricted; that is, we can use keywords such as return, break, and continue (though this is not fully implemented yet).





Here is a trivially easy block with a driver method perform that shows usage. The => symbol denotes a restricted closure (explained at the end of this post).





The concept of the closure syntax is that it is a series of statements, ending in an expression (i.e. no semi-colon). The expression is returned to the calling method. If we mentally substitute the closure code into the calling method (shown below), this seems (somewhat) intuitive.



The Problem

Here, the issue of Tennent's Correspondence Principle (TCP) comes in. The idea is that any code or keywords used in the closure should behave the same as though the code were situated inside the calling method. If you think about it in terms of substitution, this seems reasonable.

However, for unrestricted closures, this means we can have return statements that are non-local: that is, they do not simply return from the closure itself, but instead from the calling method (e.g. withTransaction above).

Because this behaviour is different from older anonymous inner classes, some people are very concerned about cut-and-paste errors and a general misunderstanding of the code.

In my opinion, this is a good debate. However, no one seems to address the issue that syntax highlighting can offer visual cues to the reader. In other words, syntax highlighting doesn't have to follow the TCP.

We may be able to use context to render code differently.



Complex Block

Let's take our contrived example one step further. Imagine the list of names can contain a poison pill that alerts the program to stop creating Employees.

Here is the code, as is typically shown on blogs:



I know: gaaaah! It's rough on the eyes and the return statement seems very strange: we want to reconcile the return with the ending expression that results in an Employee.

Remember, it works like this:

• if the poisonPill is given, the return is non-local and so withTransaction will return (think substitution)
• if the poisonPill is not given, the ending expression is, well, returned, though in terms of substitution one might say it is used.
  

Tricky, yes? Indeed. But how would we view this code in real-life? Eventually, we would see it through the lens of an IDE; I contend that this lens could use colour to provide visual cues to the user:




That is, return may behave the same inside a closure (satisfying TCP) but it doesn't have to be displayed in the usual way.

The Upshot

Colour your world: syntax highlighting may mitigate Tennent's Correspondence Principle and soften the syntax of all the closure proposals (not just BGGA).

P.S.

With the new prototype, restricted closures (which use =>) are not allowed to use the keywords return, break, continue. Unrestricted closures (with ==>) are allowed.

Though foreshadowed by Neal in the past, this is a new development.