To be perfectly honest your re-formatting is actually worse, to my eye. Which is surprising because Z is already ugly! You've made it longer, moved the condition away from the if (that is really mental!), and added a rather spurious looking comma (which has problems that I describe below). Actually, Z looks a lot like Common Lisp or Elisp, fully normalized. Let's say “fully normalized” means: indent everything that could be, aligned with the operand. E.g. here's Z:
defun map f xs
if unit? xs
unit
cons f car xs
map f
cdr xs
Here's Lisp:
(defun map (f xs)
(if (unit? xs)
unit
(cons (f (car xs))
(map f
(cdr xs)))))
I don't think any Lisper would really complain about that code if she came across it. That is actually how I would write it when coding in Elisp or Common Lisp, with two exceptions: Perhaps for the that "defun" and other def-* forms are often indented only two spaces after the parent's offset. Now, I thought about allowing that, and that's a good point, stylistically. But it seems not to change the overall z-expressions point much. To argue about needing editor support would also be to argue against Lisp or Python, in which case there are other people interested in arguing about that.
The Lisper might also complain, if she were being stringent, about the “map f …” being line-separated. And for that I'll say, ok. Too bad. Personally, I find myself line-separating arguments in Haskell and Lisp more often than not, so it's not a use-case I would feel the need to optimize.
Regardless, you can pretty much ignore all I said above, because it's just an aesthetics thing, kind of irrelevant to the core concept. The whole point of the indentation and right-associative application is for the Markdown-inspired macros: everything after the name is up for grabs for a macro (or special operator). The idea of adding a comma pretty much negates that and the whole point of z-expressions. If I could have commas, if I were to make that concession, I'd just have parentheses, and use s-expressions and reader macros.
I see what you mean. A separator doesn’t work with the concept at all. Apart from that, my reformatting still has two distinct advantages: it does not require a fixed-width typeface, and indentation is not affected by the lengths of identifiers. It’s silly to format code in such a way that you need to re-indent just because you renamed a function.
The Lisper might also complain, if she were being stringent, about the “map f …” being line-separated. And for that I'll say, ok. Too bad. Personally, I find myself line-separating arguments in Haskell and Lisp more often than not, so it's not a use-case I would feel the need to optimize.
Regardless, you can pretty much ignore all I said above, because it's just an aesthetics thing, kind of irrelevant to the core concept. The whole point of the indentation and right-associative application is for the Markdown-inspired macros: everything after the name is up for grabs for a macro (or special operator). The idea of adding a comma pretty much negates that and the whole point of z-expressions. If I could have commas, if I were to make that concession, I'd just have parentheses, and use s-expressions and reader macros.