(print "hello")
vs print("hello")
So to the extent Lisp is paren-heavy, it's more a stylistic thing. Lisp programmers tend to chain up calls more. (print "hello")
vs print("hello")
So to the extent Lisp is paren-heavy, it's more a stylistic thing. Lisp programmers tend to chain up calls more.Indeed. If you want less parens, use Haskell or Forth.
(-b + sqrt(b*b - 4*a*c)) / (2*a)
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
It does depend on your use case.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.
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.
{-(b) + {sqrt((b * b) - (4 * a * c)) / (2 * a)}}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.
b fnegate b b f* 4 a c f* f* f- fsqrt f+ 2 a f* f/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.
Furthermore, Lisp uses zero parentheses for grouping in order to override precedence. These parentheses don't exist in Lisp.
In print(2/(2+4)), we actually have two kinds of parentheses, because two different grammar rules use the same token.
C has even more parentheses. The parentheses in for (;;) are not the same as those in 2/(2+4) which are not the same as those in (double) p, which are not the same as those in p(42).
Lisp has parentheses that do one darn thing in the read syntax---at least when they are not literal as in "(" or #\(.
main = putStrLn "hello"
And that's just talking about syntax. The type system complicates matters further.