Of course you can implement what you're talking about in Lisp.
One big difference between Lisp and other languages is that nothing is fixed and you've control on what the reader does on every single character of the input source code. Literally.
Consider for example the project CL-Python and its mixed-syntax Lisp/Python mode.
Basically in that mode if what you type starts with an open parenthesis then it's considered Lisp, otherwise it's considered Python (including multi-line constructs).
...HOWEVER...
this kind of macro/reader-macro library is implemented rarely, because one of the main advantages of the s-expression approach is that it's well composable and you can build other macros on top of existing macros, raising the level of the language.
Once abandoned the regularity of s-expression approach, writing macros becomes annoying because to write code that manipulates code you need to consider the several different constructs of the language, precedence rules, special rules, special syntax forms.
Languages that are not based on s-expression sometimes provide real macro processing capability but working on the AST level, i.e. after some parsing processing has already been done in a fixed way. Moreover the macro code in these languages looks really weird because the code the macro is manipulating, inspecting or building doesn't look like real code.
Sometimes in other languages instead you only find text-based macros that are basically search-replace. To see an example of how ugly things can get consider the Python standard library implementation of collections.namedtuple (around line 284) and its set of absurd limitations induced just because of that implementation.
Another example of how things can get horribly complex once you force yourself to a template-only approach to avoid the complexity of manipulating an irregular and special cased language is C++ template metaprogramming.
A simple s-expression based language and quasi-quotation instead makes macro code much easier to write and read and understand, and that's why Lisp code doesn't move away from it. Not because it cannot, but because it doesn't make sense to go to a worse syntax for no reason.
In Lisp you "bend" the language a little by adding the abstractions that are really needed without however breaking everything else and, most important, without dropping the ability to do more bending in the future if needed. Writing a macro/reader-macro that makes the expression parsing the nightmare of say C++ and at the same time removes the ability to write further macros and add more constructs (or makes it impossibly hard) would be a nonsensical suicide.
Even a macro like (infix x + y * z)
is just an exercise... I doubt that any lisper would use that to write real code... why on earth would someone reintroduce the absurd function/operator duality and the nightmare of precedence/associativity rules? If you don't like Lisp then just don't use Lisp.
For a lisper it's not the (infix
and )
part that is ugly... it's what is in the middle.
Also why do you think that 2+3*6 is "naturally" 20? Because the teacher hit you on the palms of your hands with a stick when you were a kid until you got it right?