4 ms·

I have a pet theory that someone will put a Python skin on Clojure and have significant success with it.

SapphireSun 11y ago
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 11y 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 11y ago
    Thanks, I learned something today. :)
- pjmlp 11y ago
  Dylan also has macros.
  - groovy2shoes 11y ago
    As does Rust.
    - pjmlp 11y ago
      But Rust isn't a Lisp based on M-Expressions like Dylan is.
      - groovy2shoes 11y 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 11y 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 11y ago
Well, there's already wisp/sfri-110 for scheme, it appears the preprocessor should mostly work with clojure -- although one would probably want to port it over, or at least try to get it working on the jvm in order to have it "work where clojure works" (I have no idea how viable it would be to get it running with jython and something like kawa scheme out of the box): http://www.draketo.de/english/wisp#text-table-of-contents http://www.draketo.de/english/wisp#text-table-of-contents [ed: For Racket, see also: https://github.com/takikawa/sweet-racket https://github.com/takikawa/sweet-racket ] [ed2: See also the "readable" package for Common Lisp and for Scheme: https://sourceforge.net/p/readable/wiki/Install-howto/ https://sourceforge.net/p/readable/wiki/Install-howto/ ]

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 11y 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 11y ago
  Thanks, I learned something today. :)
pjmlp 11y ago
Dylan also has macros.
- groovy2shoes 11y ago
  As does Rust.
  - pjmlp 11y ago
    But Rust isn't a Lisp based on M-Expressions like Dylan is.
    - groovy2shoes 11y 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 11y 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 11y ago

Well, there's already wisp/sfri-110 for scheme, it appears the preprocessor should mostly work with clojure -- although one would probably want to port it over, or at least try to get it working on the jvm in order to have it "work where clojure works" (I have no idea how viable it would be to get it running with jython and something like kawa scheme out of the box): http://www.draketo.de/english/wisp#text-table-of-contents http://www.draketo.de/english/wisp#text-table-of-contents [ed: For Racket, see also: https://github.com/takikawa/sweet-racket https://github.com/takikawa/sweet-racket ] [ed2: See also the "readable" package for Common Lisp and for Scheme: https://sourceforge.net/p/readable/wiki/Install-howto/ https://sourceforge.net/p/readable/wiki/Install-howto/ ]