As I see it, haskell is all about the type system, and macros are all about circumventing the limits of the type system. These things seem at odds.
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.
This page has some useful information about phases: https://docs.racket-lang.org/guide/phases.html
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.
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.
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.