[beeworker]

One difference is flow control. When you call a function, all the arguments are evaluated before being passed into the function. If you want to delay evaluation, you have to wrap the argument values in a function. When you call a macro, the text forms get passed with no evaluation.

Say Clojure forgot to ship with the boolean "or". "or" should evaluate its arguments one at a time (to allow for short circuiting) and return the first non-false value. You could do this with functions, but you have the source-level overhead of manually wrapping everything, and performance overhead of defining and passing an anonymous function for each argument. With a macro, at compile time you just translate the "or" macro into a simpler form that uses "if". This is how Clojure actually implements "or":

    (defmacro or
      "Evaluates exprs one at a time, from left to right. If a form
      returns a logical true value, or returns that value and doesn't
      evaluate any of the other expressions, otherwise it returns the
      value of the last expression. (or) returns nil."
      {:added "1.0"}
      ([] nil)
      ([x] x)
      ([x & next]
          `(let [or# ~x]
             (if or# or# (or ~@next)))))

[platz]

I wonder how much macros are necessary one you add call-by-name parameters e.g. scala.

[p4bl0]

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.

[vog]

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

[jlarocco]

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.

[mbrock]

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.

[platz]

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

[wtetzner]

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.

[kazinator]

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?"