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.
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.