4 ms·

You can't. The reason you can use macros so easily in LISP is because of homoiconicity: https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wik

You can't. The reason you can use macros so easily in LISP is because of homoiconicity: https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity Your macros will break all over the place in languages that don't have this property.

e12e 10y ago
SRFI-110 says you can^1: "Sweet-expressions are general and homoiconic, and thus can be easily used with other constructs such as quasiquoting and macros. In short, if a capability can be accessed using s-expressions, then they can be accessed using sweet-expressions. Unlike Python, the notation is exactly the same in a REPL and a file, so people can switch between a REPL and files without issues. Fundamentally, sweet-expressions define a few additional abbreviations for s-expressions, in much the same way that 'x is an abbreviation for (quote x)." http://srfi.schemers.org/srfi-110/srfi-110.html#wisp http://srfi.schemers.org/srfi-110/srfi-110.html#wisp ^1 [ed: well, not "just python syntax", but if you wanted that, you would be better off using python. But python-like syntax/skin is absolutely doable. ]
- SapphireSun 10y ago
  Thanks, I learned something today. :)
pjmlp 10y ago
Dylan also has macros.
- groovy2shoes 10y ago
  As does Rust.
  - pjmlp 10y ago
    But Rust isn't a Lisp based on M-Expressions like Dylan is.
    - groovy2shoes 10y ago
      No, but it's also not a homoiconic language, and it supports syntactic macros just fine. Homoiconicity might make procedural macros convenient, but it's far from a requirement. And then pattern-template macros are just as convenient in a more "syntactically rich" language as they are in a homoiconic one. See also: camlp4/camlp5. And then there's the idea of pattern-match rewriting systems. iirc, GHC has something like that to rewrite certain expressions as optimizations, like: (map f) . (map g) => map (f . g) In a pure language, the two expressions are equivalent, but the latter is more efficient because it traverses the list only once rather than twice. The Cat programming language had a similar sort of "macro" system, but its web site seems to have disappeared. Shame, it was a really neat little concatenative language. Homoiconicity is certainly neat, but it's not about macros at all. It's about having a Lisp-style `read` function. That's it. Also, Dylan's syntax wasn't based on M-expressions per se, at least not in the "classical" LISP 1.5 sense of the term. It was just an Algolesque syntax rather than a façade layered above S-expressions. If you can claim that Dylan was based on M-expressions, then you could just as truthfully claim that Lua, Ruby, JavaScript, etc. are based on M-expressions. I won't say that it's strictly false, but I don't think that's quite how most people familiar with M-expressions think of them.
      - pjmlp 10y ago
        > Also, Dylan's syntax wasn't based on M-expressions per se, I know, my remark was more into the sense of being based as departure point, not as being a pure M-expression implementation.

e12e 10y ago

SRFI-110 says you can^1: "Sweet-expressions are general and homoiconic, and thus can be easily used with other constructs such as quasiquoting and macros. In short, if a capability can be accessed using s-expressions, then they can be accessed using sweet-expressions. Unlike Python, the notation is exactly the same in a REPL and a file, so people can switch between a REPL and files without issues. Fundamentally, sweet-expressions define a few additional abbreviations for s-expressions, in much the same way that 'x is an abbreviation for (quote x)." http://srfi.schemers.org/srfi-110/srfi-110.html#wisp http://srfi.schemers.org/srfi-110/srfi-110.html#wisp ^1 [ed: well, not "just python syntax", but if you wanted that, you would be better off using python. But python-like syntax/skin is absolutely doable. ]

SapphireSun 10y ago
Thanks, I learned something today. :)

pjmlp 10y ago

Dylan also has macros.

groovy2shoes 10y ago
As does Rust.
- pjmlp 10y ago
  But Rust isn't a Lisp based on M-Expressions like Dylan is.
  - groovy2shoes 10y ago
    No, but it's also not a homoiconic language, and it supports syntactic macros just fine. Homoiconicity might make procedural macros convenient, but it's far from a requirement. And then pattern-template macros are just as convenient in a more "syntactically rich" language as they are in a homoiconic one. See also: camlp4/camlp5. And then there's the idea of pattern-match rewriting systems. iirc, GHC has something like that to rewrite certain expressions as optimizations, like: (map f) . (map g) => map (f . g) In a pure language, the two expressions are equivalent, but the latter is more efficient because it traverses the list only once rather than twice. The Cat programming language had a similar sort of "macro" system, but its web site seems to have disappeared. Shame, it was a really neat little concatenative language. Homoiconicity is certainly neat, but it's not about macros at all. It's about having a Lisp-style `read` function. That's it. Also, Dylan's syntax wasn't based on M-expressions per se, at least not in the "classical" LISP 1.5 sense of the term. It was just an Algolesque syntax rather than a façade layered above S-expressions. If you can claim that Dylan was based on M-expressions, then you could just as truthfully claim that Lua, Ruby, JavaScript, etc. are based on M-expressions. I won't say that it's strictly false, but I don't think that's quite how most people familiar with M-expressions think of them.
    - pjmlp 10y ago
      > Also, Dylan's syntax wasn't based on M-expressions per se, I know, my remark was more into the sense of being based as departure point, not as being a pure M-expression implementation.