> I have to admit I have no idea what racket is, nor did I do much more than scan the article.

why have you commented then? Mao Zedong had a dope saying about this, "No investigation, no right to speak!"

-----------------------------

One answer to your questions, btw, is that macros are useful and interesting regardless of what kind of type system you have. Haskell has something called Template Haskell, which is really quite bad for a number of reasons, but it is certainly possible to imagine a version of Haskell with a well-designed macro system. It just so happens that Racket has an exceptionally well-designed macro system, so the partnership of the two ideas is very plausible and scientifically interesting.

Macros and types are not in opposition. However, macros induce a notion of PHASE which is not usually accounted for in type systems, though it may be possible to account for this in a principled/type-theoretic way using ideas from modal logic and kripke semantics.

Could you explain what phase is? I understand haskell types, and I suspect Template haskell mostly works as an AST translator. A Google search on macros and phase, just turns up diet and bodybuilding preparation advice!

In the simplest case, a macro system gives rise to two-phase evaluation - first, there is code that runs at macro expansion time, that produces, as its result, new syntax, and second, that resulting code runs. But having just two phases is (needlessly) restrictive, because you might want macros that generate other macros (and so the macro-generating macros would need to run at an earlier phase than the generated ones).

Wouldn't the macro-expansion phase be run until it reaches a fixed point? That way all macros could be fully expanded before proceeding to the next phase.

I believe that's how macros in Racket work, but each iteration is considered a separate phase. At least, that's how I understood it.

This page has some useful information about phases: https://docs.racket-lang.org/guide/phases.html

> why have you commented then?

To learn, not about racket, but about the point of macros. It seems to have worked. I was going for something along the lines of Cunninghams law.

Anyway, thanks for the insight on macros.

Do you have any good links about Template Haskell? I've heard of it before, but I'm curious what the main drawbacks are :)

So far as I'm aware, the drawbacks to Template Haskell are:

1) Debugging generated code can be a pain. To some degree this is true of most macro systems, but it certainly applies here.

2) It adds to build times, sometimes significantly.

3) There is an issue preventing use of Template Haskell when cross compiling.

Some other things of note:

The Haskell syntax is really complicated, compared to s-exprs. This is not entirely negative - variated syntax can help you know where you are in an expression and give more guidance when you mix things up - but it's not entirely positive either.

The stage restriction prevents using a piece of Template Haskell in the same module where you define it. For a lot of use cases, this doesn't matter... but it makes module-specific one-offs more awkward, moving their definition away from where they're relevant.

As of comparatively recent, there is "Typed Template Haskell". As originally conceived, Template Haskell generating an expression didn't "have to" produce an expression of the right type. Compilation would still fail once the type mismatch was detected, but further from the cause of the error.

Macros are absolutely not a way to get around the type system. The things macros let us do are mostly orthogonal to types and there is no contradiction to having macros in a typed language. In fact, that's exactly what Template Haskell is—a macro system for Haskell. It just happens to be awkward to use for a variety of reasons.

I would go further: a typed language needs the sort of metaprogramming macros provide to avoid having too much boilerplate and noise. You can either do this with a simple, general macro system or with ad-hoc features addressing narrow usecases a macro system would cover. Haskell's deriving mechanism, record system and syntax sugar like do-notation are all great examples of things that would be obviated with a solid macro system, making the language simpler.

Google MacroML for an example.