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 ExampleHere 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 ProblemHere, 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 BlockLet'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 UpshotColour 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.
