> you can even make your own syntactic extensions, so if infix math is necessary, then you can
have it
...in what Lisp and how can one do this?
...in what Lisp and how can one do this?
If you were to set out to do this, the first thing you'd have to accept is that the macro is going to look a little weird. For instance:
(infixmath 2 + 3 * 4 * (2 + 1))
Once you've written your recursive descent parser to handle infix math, you'll face the next challenge: what to do with the parse tree. The simplest thing to do is just evaluate it. If you were really clever you might be building a Lisp prefix expression as you went and you can just let Lisp evaluate that directly with eval. A part of you will wonder if you should instead generate a compiled function, but then you have to capture the variables properly and it will be a lot more work, but it could become more efficient, since the Lisp compiler would have access to that information and could do better things with it...
Anyway, my point is that this is sort of a will-o-the-wisp or mermaid example, because it's intended to capture the imaginations of non-Lispers, but actual Lispers have never actually gotten serious enough about it to make a robust implementation and ship it with the system, because the mindset that values infix math is incompatible with the mindset that produces good Lisp programmers.
As for why you do not see it done in practice, I would say it is mainly because it is not terribly useful in practice. Infix notation is just what most people are comfortable with, because they learned it in school; it has no real technical advantage, and the need for precedence rules is something of a disadvantage (though not a terribly major issue).
The reason you perceive this as not terribly useful in practice is my overall point: once you're good enough with Lisp to develop this, you think in terms of s-exps and don't see the point. The primary technical advantage of infix notation is that the book you're getting the formula from used it, so it's easier to see if you transcribed it correctly. A secondary advantage is that it's what you use in your head and on paper. If the advantages of Lisp syntax outweigh the advantages of a lifetime of schooling and compatibility with the world at large, you are, at last, a Lisper. :)
I don't think mindlessly transcribing formulas from textbooks is a strong argument for infix notation, and it is definitely not a technical advantage. I am not entirely sure that infix is what people naturally use internally, either, as it is not unusual to hear people say things like, "subtract 3 from x" or "divide the sum of the numbers by the count" -- those look more like something you would see in Lisp than infix notation to me.
But seriously, now. Reverse Polish notation is plenty intuitive as long as you don't get too crazy with what you put on the stack.
For example,
(7**3 + 9*7) / 2
7 3 ** 9 7 * + 2 /
(((7 3 **) (9 7 *) +) 2 /)
P.S. You'll notice that with parentheses RPN looked remarkably Lisp-like. This isn't a coincidence. The core difference between prefix notation as used by Lisp and RPN is that operators in RPN may only take two arguments (it's more complicated in languages like Forth, but since we're talking about arithmetic here we can safely make this assertion). This is the tradeoff RPN makes: losing the ability to have n number of arguments per operator, for the ability to ditch those parentheses for good.
It should also be clear that one could easily have a Lisp-like syntax similar in appearance to the RPN with parentheses above (though with Lisp's ability to have more than two arguments), but just happening to put operators at the end. Conversely, one could have an RPN where operators are at the front, which is actually the concept behind Polish notation, where RPN stems from: http://en.wikipedia.org/wiki/Polish_notation
On a final note, since RPN is read from left-to-right exclusively, a speaker of an RTL language would actually be worse off. The perceived unintuitiveness is more because English is a subject-verb-object language, whereas RPN is subject-object-verb.
and the fact that fixed arity for an operator or function makes parentheses unnecessary is cool... never thought of that before :)
( ...big thing 1... ) + ( ...big thing 2...)
...but then again, "purer" languages like Haskell don't use prefix (yes, it's an alternative, but people just don't use it). And mathematical language, that is not imperative and sometimes not even sequential, uses infix. And List never made a fuss about being a "pure" functional language... it's more of a "multi paradingm" language. Still like Haskell's way of putting the operator on parentheses for prefix in infix by default, though H will definitely never be my favorite language...
(+ ( ... big thing 1 ...)
( ... big thing 2 ...))
Haskell is my favorite language, but I find I get a lot more use out of converting words to operators than converting operators to "words." For example, I find this:
x `elem` y
elem x y
...but it's that different feeling that "add 'big thing 1' with 'big thing 2'" vs. "compute 'big thing 1' and then add 'big thing 2' to it" ...and if you think of a programming language as an "interface" between your mind and the computer, and think of a programming language from a UI or UX design perspective, these subjective "how it feels" things really do matter. But indeed, Haskell wins on this one 100% by allowing you to just use whatever notation you like without having to write or use a reader macro or something like this. Anyway, back to real work now...
I suspect most Lisps would require about the same.
("infix")
CL-USER> #I(abs(-4)+5^^2-6)
-23