There's a perceptual litmus test here. Some people see life on earth and see God. Others see the faintest exploration of the design space, an impoverished code base that made it impossibly far. A miracle, perhaps, but not what we'd see in a billion runs of the simulation.
Same with Lisp macros. Their few variants look bolted on. We haven't begun to explore the design space, yet the best macro systems in other languages are copies of what lisp has figured out so far.
There's an 80:20 rule for language emergence. Ecosystem questions aside, a Turing-complete language needs to start by getting one thing right. APL leveraged multidimensional array handling into a general purpose language. Scripting languages gain much of their leverage from nested hash tables.
Concise versions of monadic parsing are exhilarating in their power and expressiveness. If a language was designed so parsing and manipulating itself was its sweet spot, generalizing this parsing to typed trees would be easy, and we'd invent many new programming paradigms. A general purpose language would follow.
Lisp, an implementation of the lambda calculus, is not this language. Lisp is a machine language precursor to this idea, with various macro systems bolted on.
Haskell, an implementation of typed category theory, is not this language either. At the expression level, Haskell is stuck at a few hard-wired pattern matching primitives. Haskell does not make the assumption that everyone has learned to compose arbitrary parsing operators.
the racket lang team has investigated this heavily.
https://www.youtube.com/watch?v=ABWLveMNdzg
https://www.cs.utah.edu/plt/publications/popl16-f.pdf
https://www.cs.utah.edu/plt/scope-sets/
> Haskell, an implementation of typed category theory
These are going to be controversial assertions in a Lisp thread, but I believe
1. C++ Templates + Concepts is a good Macro facility
2. Most of what makes it good is not borrowed from Common Lisp
On the other hand, I agree strongly with this assertion:
> Scripting languages gain much of their leverage from nested hash tables.
(defgeneric do-something (object))
(defmethod do-something ((object foo))
(something every foo can do))
;; bar is the same as foo
(defmethod do-something ((object baz))
(something only bazzes should do))
I think I said as much in my comment.
> This seems more akin to Common Lisp's defgeneric and defmethod
Except that Templates are statically dispatched and type-checked.
But also one can perform meaningful compile-time computation with them - I have used this in anger to implement stencils and iteration logic for partial differential equation solvers in 1-3 dimensions so I can say from experience that it is not a mere curiosity. And I don't think that CLOS really has any analog for the techniques used to implement std::tuple.
> But macros let you do something else entirely. You can create entirely new syntactic structures, or modify existing functions (see Norvig's PAIP, chapter 9, where macros are used to memoize recursive functions), or any number of other things.
I think the thrust of my comment is that Lisp programmers identify this type-blind AST-mapping functionality as the core of "a Macro System," while users of other languages (with more syntax to begin with) see this as somewhat secondary to the goal of type-checked compile-time computation.
Cue arguments, I guess, about whether Scheme is a Lisp, whatever their standards say.
It would just look weird as fuck.
Lisp macros look like Lisp and in manipulating code via macros you can leverage the rest of Lisp and Lisp's ecosystem.
So writing Lisp macros is entirely natural for someone who already knows Lisp. You don't have to learn or use what is effectively a separate language, as you do with every other language that's not homoiconic.
As Alan Perlis once said, "Beware the Turing tarpit, where everything is possible and nothing is easy."
Most of them arguably qualify as being somewhere between an 80% solution and a 90% solution for the practical problems that lisp might solve with macros.
They're frequently not anywhere near as convenient to use or understand. But that's arguably a good thing in the long run, because it encourages communities to pool resources and work on a coordinated solution that can be shared by the community. My take on the curse of lisp, for what it's worth, is economies of scale. Lisp makes it too easy (and fun) to just keep your head down and work on your own thing, which hinders pooling of resources.