CBCL: The Common Business Communication Language

I recently came across McCarthy’s CBCL paper on Hacker News. He presents a Lisp notation as a format for sharing requests between different software on different computers. He calls out

(PLEASE-RESERVE (EPSILON (x) 
  (AND
    (IS-FLIGHT x) 
    (DEPARTS MONDAY) 
    (ARRIVES (BEFORE WEDNESDAY)))))

where $\epsilon x$ is an operator maps a predicate to a value matching the predicate, and considers it an improvement on the “iota” definite description operator, which seems to be an operator that returns the unique value matching the predicate. It seems interesting to me that the unique match operator is not considered as useful as the arbitrary match operator – unique keys actually seem critical to a lot of my work with data models. Even more fascinating, though, is that this looks like an anonymous function!

I did a bit more reading, and it turns out that those definite descriptions are probably actually a reference to the domain relational calculus introduced by Lacroix and Pirotte.

McCarthy is very dismissive of XML as an inferior format to Lisp notation, but I am a bit less convinced that XML’s addition of a schema doesn’t add anything. Enumerating possible values a given request can take on – that is, a specification – seems very fruitful in the distributed systems work that I have done, to say little of how nice a standardized, portable, relatively compact, battle-tested specification and serialization format is. But perhaps McCarthy doesn’t mention it because he is assuming that the Lisp notation could also have a schema/specification overlayed on top of it, and which was itself a Lisp notation definition. It almost seems like variant of the robustness principle, which has of course been refuted.

Finally, I’m interested in applying these lessons to the things that came after McCarthy’s 1999 update. In particular, protocol buffers. Here, we find an even stronger schema and a ton of other features not exactly relevant to the CBCL proposal, but interesting none-the-less. I was especially struck by the description of the ADJECTIVE modifier for specifying “extra” details about a particular type of object, and the similarity to protobuf optional fields. Specifically,

The point of ADJECTIVE is that a program not understanding YELLOW could nevertheless understand that #2 pencils were called for, and could reply that they don’t have any pencils, if that were so.

ends up sounding a lot (but not exactly) like an optional protobuf field–perhaps more akin to using the protobuf API to return a response that encodes “I matched all the fields I understood, but also found a field I didn’t understand”.