What I find repulsive is that macros are a micro-optimization for the author but a huge destroyer of readability. Consider a simple macro like "if-not" - just an inverted if. In a lanaguage without macros, the maintainer can be sure that there is only one construct like if. The eyes can skim over code, easily understanding semantics of the code without reading into it. Now consider the mere possibility that some if are if-nots: suddenly the mere ifs become a minefield for the reader. And if LX claims ability to eg modify the semantics of X.Y - it's going to be an unreadabe mess.

My point is, readability of code increases proportionately not just to the complexity and size of code, but also proportionately to the size of syntax. In a language with no macros, the latter is fixed and you get a linear dependency. In extensible PLs it's a quadratic one with an unknown second factor, jeesh! I think the approach with a more powerful but almost fixed language (eg Haskell where macros are hard and mostly used to generate boilerplate definitions) is better than a small but extensible language with every programmer on a contest of who makes a wittier and sleeker new control structure that is like the builtin ones but SO much cooler...

I don't know if you are aware of that, but at the time Pascal started emerging, the exact same arguments were presented by foiks used to BASIC that having the ability to add your own "words" to the language would inevitably lead to a mess.

Why didn't it happen? Because programmers overall are reasonable folks. So, yes, in theory, you can define a factorial function and call it "Not_a_Cat" (technically, it is true), but nobody does that.

Similarly, giving the ability to define `X in Y..Z` makes code more readable if you use it right, not less.