- 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.
- 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).
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
Employeesfrom a list of
Stringswithin 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
continue(though this is not fully implemented yet).
Here is a trivially easy block with a driver method
performthat 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.
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
returnstatements that are non-local: that is, they do not simply return from the closure itself, but instead from the calling method (e.g.
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.
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
returnstatement seems very strange: we want to reconcile the
returnwith the ending expression that results in an
Remember, it works like this:
- if the poisonPill is given, the
returnis non-local and so
withTransactionwill 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:
returnmay behave the same inside a closure (satisfying TCP) but it doesn't have to be displayed in the usual way.
Colour your world: syntax highlighting may mitigate Tennent's Correspondence Principle and soften the syntax of all the closure proposals (not just BGGA).
With the new prototype, restricted closures (which use
=>) are not allowed to use the keywords
continue. Unrestricted closures (with
==>) are allowed.
Though foreshadowed by Neal in the past, this is a new development.