4 ms·

Right-associative function application is an excellent choice. Perl has it, and I often wish for it in Haskell when writing long compositions: f . g . h $

Right-associative function application is an excellent choice. Perl has it, and I often wish for it in Haskell when writing long compositions: f . g . h $ i x However, this kind of indentation rapidly gets out of hand, and requires some editor awareness to be remotely usable: defun map f xs if unit? xs unit cons f car xs map f cdr xs Moreover, there doesn’t seem to be any virtue in preventing multiple indentation styles. Readability often depends not on consistency, but on redundancy, and using the right style for the situation. I would much rather read and write this: defun map f xs if unit? xs unit cons f car xs map f, cdr xs That is, indentation would only introduce a block of arguments, and arguments on the same line could only span that line. If you wanted multiple arguments on one line, you could use a separator—here, a comma.

chrisdone 14y ago
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.
- evincarofautumn 14y ago
  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.
  - ericbb 14y ago
    Alexander Burger indents his PicoLisp code more along the lines you describe. Example: http://rosettacode.org/wiki/Execute_Brain****#PicoLisp http://rosettacode.org/wiki/Execute_Brain****#PicoLisp
  - chrisdone 14y ago
    That's true. I don't like reading it, but I would prefer writing it. It's pretty much why in Haskell I write: foo $ bar $ do hello world rather than foo $ bar $ do hello world You could easily have: foo bar mu be equivalent to foo bar mu but if you had foo bar bob zot mu And you rename foo, you're back to square one again (zot is no longer syntactical). Unless you just have a rule like: foobarmuzot bar bob zot mu means foobarmuzot bar bob zot mu But it seems comparatively difficult to read, and deceptive.
akkartik 14y ago
My favorite exagesis on the benefits of right-associativity: http://arclanguage.org/item?id=16820 http://arclanguage.org/item?id=16820
ohwp 14y ago
That's what I like in Notepad++ (maybe other editors have this as well). You can view tab columns. So your indent is very clear.

chrisdone 14y ago

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.

evincarofautumn 14y ago
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.
- ericbb 14y ago
  Alexander Burger indents his PicoLisp code more along the lines you describe. Example: http://rosettacode.org/wiki/Execute_Brain****#PicoLisp http://rosettacode.org/wiki/Execute_Brain****#PicoLisp
- chrisdone 14y ago
  That's true. I don't like reading it, but I would prefer writing it. It's pretty much why in Haskell I write: foo $ bar $ do hello world rather than foo $ bar $ do hello world You could easily have: foo bar mu be equivalent to foo bar mu but if you had foo bar bob zot mu And you rename foo, you're back to square one again (zot is no longer syntactical). Unless you just have a rule like: foobarmuzot bar bob zot mu means foobarmuzot bar bob zot mu But it seems comparatively difficult to read, and deceptive.

akkartik 14y ago

My favorite exagesis on the benefits of right-associativity: http://arclanguage.org/item?id=16820 http://arclanguage.org/item?id=16820

ohwp 14y ago

That's what I like in Notepad++ (maybe other editors have this as well). You can view tab columns. So your indent is very clear.