Lazy evaluation makes macros redundant
This is pure nonsense (not your fault; I’ve heard it before). It’s true that you can use macros to change the order, context, etc. of expression evaluation, but that’s the most basic use of macros, and it’s really not convenient to simulate a lazy language using ad-hoc macros instead of functions. So if you came at macros from that direction, you would indeed be disappointed.
Macros are for extending the language with new syntactic forms. Some of the specific capabilities of macros are
- Affecting the order, context, etc. of expression evaluation.
- Creating new binding forms (i.e. affecting the scope an expression is evaluated in).
- Performing compile-time computation, including code analysis and transformation.
Macros that do (1) can be pretty simple. For example, in Racket, the exception-handling form, with-handlers, is just a macro that expands into call-with-exception-handler, some conditionals, and some continuation code. It’s used like this:
(with-handlers ([(lambda (e) (exn:fail:network? e))
(lambda (e)
(printf "network seems to be broken\n")
(cleanup))])
(do-some-network-stuff))
The macro implements the notion of “predicate-and-handler clauses in the dynamic context of the exception” based on the primitive call-with-exception-handler which handles all exceptions at the point they’re raised.
A more sophisticated use of macros is an implementation of an LALR(1) parser generator. Instead of a separate file that needs pre-processing, the parser form is just another kind of expression. It takes a grammar description, computes the tables at compile time, and produces a parser function. The action routines are lexically-scoped, so they can refer to other definitions in the file or even lambda-bound variables. You can even use other language extensions in the action routines.
At the extreme end, Typed Racket is a typed dialect of Racket implemented via macros. It has a sophisticated type system designed to match the idioms of Racket/Scheme code, and it interoperates with untyped modules by protecting typed functions with dynamic software contracts (also implemented via macros). It’s implemented by a “typed module” macro that expands, type-checks, and transforms the module body as well as auxiliary macros for attaching type information to definitions, etc.
FWIW, there’s also Lazy Racket, a lazy dialect of Racket. It’s not implemented by turning every function into a macro, but by rebinding lambda, define, and the function application syntax to macros that create and force promises.
In summary, lazy evaluation and macros have a small point of intersection, but they’re extremely different things. And macros are certainly not subsumed by lazy evaluation.