6 ms·

We haven't figured out macros yet. There's a perceptual litmus test here. Some people see life on earth and see God. Others see the faintest exploration of the

We haven't figured out macros yet. 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.

neutronicus 6y ago
> yet the best macro systems in other languages are copies of what lisp has figured out so far. 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.
- Jtsummers 6y ago
  I've been pondering this comment, and I'm not sure I agree that C++ Templates + Concepts are really equivalent to Lisp macros. They're about enabling generic programming with type constraints (when you add concepts, in particular). This seems more akin to Common Lisp's defgeneric and defmethod, where you can specialize your implementation based on the type. Like, assuming some class hierarchy of foo (base) -> bar -> baz: (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)) Templates and concepts are certainly a powerful tool, and I personally like them (as I've come back to C++ after a long break). 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.
  - neutronicus 6y ago
    > I'm not sure I agree that C++ Templates + Concepts are really equivalent to Lisp macros. 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.
- oalae5niMiel7qu 6y ago
  If C++ had a good macro system, the Qt library wouldn't need the "moc" preprocessor to implement its "slots" abstraction. Templates aren't powerful enough to fill that role, even when you add Concepts to them.
  - neutronicus 6y ago
    My understanding is that moc is no longer necessary, but sticks around for legacy compatibility, but I may be wrong.
nikofeyn 6y ago
> We haven't figured out macros yet. the racket lang team has investigated this heavily. https://www.youtube.com/watch?v=ABWLveMNdzg https://www.youtube.com/watch?v=ABWLveMNdzg https://www.cs.utah.edu/plt/publications/popl16-f.pdf https://www.cs.utah.edu/plt/publications/popl16-f.pdf https://www.cs.utah.edu/plt/scope-sets/ https://www.cs.utah.edu/plt/scope-sets/ > Haskell, an implementation of typed category theory http://math.andrej.com/2016/08/06/hask-is-not-a-category/ http://math.andrej.com/2016/08/06/hask-is-not-a-category/

neutronicus 6y ago

> yet the best macro systems in other languages are copies of what lisp has figured out so far. 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.

Jtsummers 6y ago
I've been pondering this comment, and I'm not sure I agree that C++ Templates + Concepts are really equivalent to Lisp macros. They're about enabling generic programming with type constraints (when you add concepts, in particular). This seems more akin to Common Lisp's defgeneric and defmethod, where you can specialize your implementation based on the type. Like, assuming some class hierarchy of foo (base) -> bar -> baz: (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)) Templates and concepts are certainly a powerful tool, and I personally like them (as I've come back to C++ after a long break). 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.
- neutronicus 6y ago
  > I'm not sure I agree that C++ Templates + Concepts are really equivalent to Lisp macros. 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.
oalae5niMiel7qu 6y ago
If C++ had a good macro system, the Qt library wouldn't need the "moc" preprocessor to implement its "slots" abstraction. Templates aren't powerful enough to fill that role, even when you add Concepts to them.
- neutronicus 6y ago
  My understanding is that moc is no longer necessary, but sticks around for legacy compatibility, but I may be wrong.

nikofeyn 6y ago

> We haven't figured out macros yet. the racket lang team has investigated this heavily. https://www.youtube.com/watch?v=ABWLveMNdzg https://www.youtube.com/watch?v=ABWLveMNdzg https://www.cs.utah.edu/plt/publications/popl16-f.pdf https://www.cs.utah.edu/plt/publications/popl16-f.pdf https://www.cs.utah.edu/plt/scope-sets/ https://www.cs.utah.edu/plt/scope-sets/ > Haskell, an implementation of typed category theory http://math.andrej.com/2016/08/06/hask-is-not-a-category/ http://math.andrej.com/2016/08/06/hask-is-not-a-category/