You should have a look at Kernel, vau-calculus and F-expressions. Kernel merges the notions of first-order functions and macros by having lexically scoped definition of Fexprs which takes their argument by name and also receives the call-site environment so that you can eval the argument in it if needed.

I find it a very elegant way of having everything clean, "lambda" does not even have to be a primitive anymore.

Or, once you have lazy evaluation (like in Haskell), for that matter.

Laziness can achieve a similar thing in that case (less elegantly, IMO), but there are other uses for macros that can't be solved with laziness.

Look at the uses for Template Haskell, for example.

That's basically Haskell's macro system. And it's used quite a lot, though it's kind of arcane.

If you want to create an abstraction that defines one or several data types, you'll think hard about whether you can use some kind of type-level programming instead—but if that's not possible, or not convenient, you can use TH macros.

For example, the `lens` package defines TH macros for creating special kinds of accessors that are tedious to write by hand.

using macros to deal with boilerplate, although useful, though is of a different order than things that simply cannot be expressed without macros

Which things cannot be expressed without macros? Macros run at compile time, and just output normal code in the language.

I think being able to generate types is a very useful and important use of macros. In fact, (depending on whether or not your macros can have side effects) you could use macros to implement something like F#'s type providers.

Search down for my comment which contains the substring:

"if I have a non-strictly evaluated language with higher order functions, do I still need macros?"