[mpweiher]

>> ... use the least powerful mechanism ...

> ... providing tools ...

Use ≠ provide. :-)

See:

The Rule of Least Power, Tim Berners-Lee

https://www.w3.org/2001/tag/doc/leastPower.html

See also:

Rule of least expressiveness

When programming a component, the right computation model for the component is the least expressive model that results in a natural program.

From Concepts, Techniques, and Models of Computer Programming, Peter van Roy, https://www.info.ucl.ac.be/~pvr/book.html

[m00natic]

I was more after

> The question is whether you want that sort of power in day-to-day programming

It's good to use the least powerful mechanism, no doubt. But it seems you are trying to sneak the usual "macros are too powerful for everyday use" so better be left out of a language altogether? I think when the storm comes - you'd better be equipped. Having varied ways to tackle problems (and macros are sort of linguistic abstraction orthogonal to lambda calculus/Turing machine derived toolboxes) allows for less complex solutions.

[mpweiher]

> sneak the usual "macros are too powerful for everyday use"

Not trying to "sneak" anything, I openly say that language design, which is what macro usage is, is not something you should have to engage in everyday. In fact, I would turn it around: if you have to (repeatedly) resort to language design in your everyday programming, your programming language is (woefully) inadequate. Most are.

Which is why the reasons for hitting that boundary interest me: where do I have to resort to metaprogramming, why, and what can I do about it? What non-metaprongramming facilities are missing here so that I don't have to resort to metaprogramming? And if I don't want to just add those facilities to the base, which I don't, what mechanisms can I add to the language so that users of the language can use plain, non-meta mechanisms to provide those facilities themselves?

This is a bit tricky, but I am making good progress using a software architectural approach[1], with frequent surprises as to how much simpler things can be.

> left out of a language altogether?

Quite the contrary. I think "escape hatches" (metaprogramming) are fundamental and your everyday language(s) should be built 100% on top of those mechanisms. Heck, I named my company "metaobject"[2] 20 years ago, after The Art of Metaobject Protocol.

[1] http://objective.st/

[2] http://www.metaobject.com/