5 ms·

these days many newer languages have macros: lisp is not alone

by alehander42 6y ago

dreamcompiler 6y ago
C has macros. They are nothing like lisp macros. Please cite a non-lisp language with macros a powerful as lisp's.
- krebs_liebhaber 6y ago
  Elixir. https://elixir-lang.org/getting-started/meta/macros.html https://elixir-lang.org/getting-started/meta/macros.html
- plinkplonk 6y ago
  Julia
  - dreamcompiler 6y ago
    Julia is lisp in drag so it doesn't really count, but I'll give you the point.
    - dTal 6y ago
      In what sense is Julia a lisp in drag? I'm just starting in on it it doesn't seem any more lispy than any other dynamic language. In particular I've yet to see a car/cdr.
- JeremyBanks 6y ago
  Rust?
- deleted 6y ago
  [deleted]
- mumblemumble 6y ago
  C macros and lisp macros (In particular, I'm thinking of hygienic macros à la Scheme) are two wildly different extremes. In between them lies a huge continuum of interesting things. There are Scala's macros. There are Haskell's language extensions. There are code generators like the ones used to implement much of gRPC, and there are compiler plugins like the ones used to implement aspect-oriented programming in C# and Java. 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.
- loudlambda 6y ago
  Scala, Nim, Clojure, Haxe
  - dreamcompiler 6y ago
    Clojure is a Lisp so it doesn't count.
- orbifold 6y ago
  Haskell, OCaml
- pmoriarty 6y ago
  The major advantage of Lisp macros over macros in other languages aren't their power but the fact that using Lisp's macro system is virtually the same as using the rest of Lisp. 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."
tolsen718 6y ago
I don't think another language's macros can match lisp macros unless the other language is also homoiconic.
- neutronicus 6y ago
  Clojure is weakly heteroiconic and seems to have rough parity
  - fiddlerwoaroof 6y ago
    Clojure is “homoiconic”: Clojure source code is represented in terms of the data structures Clojure applications manipulate. There’s nothing preventing Common Lisp from having a similar surface syntax either: a couple read macros on [ and {, and a library of normal macros would be sufficient and could probably be written over a weekend.
    - p_l 6y ago
      In fact, since Common Lisp "source code" is NOT defined in terms of text but data structures (that happen to have standard serialization/deserialization) and that's the level that macros work on, you could theoretically even make semi-algolish syntax and still keep CL's macro system. It would just look weird as fuck.
      - fiddlerwoaroof 6y ago
        Like https://readable.sourceforge.io https://readable.sourceforge.io ?
        p_l 6y ago
        That's one example, not as crazy as what's possible. Though I have to say I dislike the indent based blocks :/
- gnufx 6y ago
  Latter-day Dylan is infix with a Scheme-y macro system: https://opendylan.org/books/dpg/macros.html https://opendylan.org/books/dpg/macros.html Cue arguments, I guess, about whether Scheme is a Lisp, whatever their standards say.
Syzygies 6y ago
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.

these days many newer languages have macros: lisp is not alone

dreamcompiler 6y ago

C has macros. They are nothing like lisp macros. Please cite a non-lisp language with macros a powerful as lisp's.

krebs_liebhaber 6y ago
Elixir. https://elixir-lang.org/getting-started/meta/macros.html https://elixir-lang.org/getting-started/meta/macros.html
plinkplonk 6y ago
Julia
- dreamcompiler 6y ago
  Julia is lisp in drag so it doesn't really count, but I'll give you the point.
  - dTal 6y ago
    In what sense is Julia a lisp in drag? I'm just starting in on it it doesn't seem any more lispy than any other dynamic language. In particular I've yet to see a car/cdr.
JeremyBanks 6y ago
Rust?
deleted 6y ago
[deleted]
mumblemumble 6y ago
C macros and lisp macros (In particular, I'm thinking of hygienic macros à la Scheme) are two wildly different extremes. In between them lies a huge continuum of interesting things. There are Scala's macros. There are Haskell's language extensions. There are code generators like the ones used to implement much of gRPC, and there are compiler plugins like the ones used to implement aspect-oriented programming in C# and Java. 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.
loudlambda 6y ago
Scala, Nim, Clojure, Haxe
- dreamcompiler 6y ago
  Clojure is a Lisp so it doesn't count.
orbifold 6y ago
Haskell, OCaml
pmoriarty 6y ago
The major advantage of Lisp macros over macros in other languages aren't their power but the fact that using Lisp's macro system is virtually the same as using the rest of Lisp. 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."

tolsen718 6y ago

I don't think another language's macros can match lisp macros unless the other language is also homoiconic.

neutronicus 6y ago
Clojure is weakly heteroiconic and seems to have rough parity
- fiddlerwoaroof 6y ago
  Clojure is “homoiconic”: Clojure source code is represented in terms of the data structures Clojure applications manipulate. There’s nothing preventing Common Lisp from having a similar surface syntax either: a couple read macros on [ and {, and a library of normal macros would be sufficient and could probably be written over a weekend.
  - p_l 6y ago
    In fact, since Common Lisp "source code" is NOT defined in terms of text but data structures (that happen to have standard serialization/deserialization) and that's the level that macros work on, you could theoretically even make semi-algolish syntax and still keep CL's macro system. It would just look weird as fuck.
    - fiddlerwoaroof 6y ago
      Like https://readable.sourceforge.io https://readable.sourceforge.io ?
      - p_l 6y ago
        That's one example, not as crazy as what's possible. Though I have to say I dislike the indent based blocks :/
gnufx 6y ago
Latter-day Dylan is infix with a Scheme-y macro system: https://opendylan.org/books/dpg/macros.html https://opendylan.org/books/dpg/macros.html Cue arguments, I guess, about whether Scheme is a Lisp, whatever their standards say.

Syzygies 6y ago

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.