(let ((...)) (f (g (h u v)))
or
let u = ... in f g (h u v)
I'll take any of these two any day.
What's special about the former one is that it composes perfectly with any other tree structure using the same textural representation of trees, where the latter one is only useful in isolation - one cannot use this representation inside some other arbitrary character sequences which is to be converted to trees, because the means by which it is parsed into a tree does not compose well (unambiguously) with other means of parsing sequences of characters into trees.
Perhaps the cleverest thing about S-expressions is that they were invented before we even had a theory of parsing unambiguously followed by a proof that we cannot compose multiple of these unambiguous parsers in a way which produces another unambigous parser.
But I'll add one delightful trait: sexps split usually complex parsing stage in two simple separate ones:
- chars -> sexp
- sexp -> meaning (special forms / anticipated mental evaluation).
At least not with plain text. There's some terrfic research in composing languages - currently the best is Tratt and Diekmann's Language Boxes, which enable arbitrary syntax composition by means of the programmer specifying the syntax boundaries explicitly - which requires a more sophisticated editor than out plain text notepad variants.
With language boxes, and their prototype editor Eco, in the end, they're ultimately storing a tree of data in their own custom format - it doesn't matter what encoding is used, just as it doesn't matter whether lisp uses parens, braces or whitespace - what really matters is that you encode things deterministically into trees which can be easily reasoned about without requiring some "magic" (AI) which attempts to create a tree from a sequence of characters unambiguously, when the programmer knows and can specify exactly what he means.
Ah, and I just realized, it wasn't Parr, but Tratt that wrote the paper "Parsing: The Solved Problem That Isn't".