Lisp only has infix macros so that we can say "we have that".
Nobody in their right mind uses this stuff in production code.
It just overcomes objections. "Oh, if I start using Lisp, there is be a way to use infix, should I really need it".
Ten years and six Lisp project later, you still haven't used the infix stuff; the situation never comes.
> Nobody in their right mind uses this stuff in production code.
You sure about that? I thought the lispy approach was generally pragmatic - you use what you deem handy for your application. It this weren't the case, there would be little need for macros in the first place. I can very well imagine, say, a scientific or engineering application that would share a common infix parser for both user-provided expressions (in the UI, to be more friendly to non-lispers) and heavy math lifting in the source code.
But! Perfect splitting across lines according to a formatting algorithm which is simple, consistent, and incrementally applicable:
1.
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c))))
(* 2 a))
2.
(/ (+ (- b)
(sqrt (- (* b b) (* 4 a c))))
(* 2 a))
3.
(/ (+ (- b)
(sqrt (- (* b b)
(* 4 a c))))
(* 2 a))
4.
(/ (+ (- b)
(sqrt (- (* b
b)
(* 4
a
c))))
(* 2
a))
Now you have a sideways tree, revealing the structure of the expression, where it is immediately apparent what the operands are of the / and the + and so on.
Infix turns into a mess breakfast when it's too long for one line.
For this particular expression, I'd probably go with variant (3) in production code. Compared to the beauty of (3), the original one-liner is basically a strawman. In terms of clarity of structure, it trumps the infix also.
This is actually a very important point that is overlooked by Lisp noobs. In real Lisp code, expressions are not written all out in one line, whereby the human reader must mentally match the parentheses. Even numeric expressions that might be one-liners in Fortran or C, are split across several lines to make at least the major constituents clear in relation to the major operator.
Yes, and the first line's use case depends on the language built-in operator precedence rules to reduce the number of parens.
If you are using math formulas as an example of minimal paren usage, go with APL and have even fewer since all operators are equal precedence and associate to the right.
If you really wanted to write the quadratic formula (or math formulas in general) you could use APL and use even fewer.
https://github.com/incanter/incanter/blob/master/modules/inc...