34 ms·

Note that this is not Lisp interpreted in Python, but transpiled into Python AST on the fly. Which is how Lisps should be implemented on top of modern environme

by aasasd 5y ago

Note that this is not Lisp interpreted in Python, but transpiled into Python AST on the fly. Which is how Lisps should be implemented on top of modern environments. (IIRC the ‘gisp’ project takes that approach even further: it transpiles a Lisp to the AST, and then spits out Go code that would generate the same AST: https://github.com/jcla1/gisp https://github.com/jcla1/gisp)

kubb 5y ago
The mapping of the AST onto lisp plus an implementation of macros would solve all the issues with Go verbosity, lack of generics, error handling, and probably much more. But it would have a lot of braces so junior programmers wouldn't be able to use it and so it's a non starter.
- aasasd 5y ago
  You can translate an analogous syntax of your choosing into the same lists =) E.g. something Python-ish or Yaml-ish, or Rebol.
  - gilch 5y ago
    See Hebigo's Python-like approach: https://github.com/gilch/hissp#hebigo https://github.com/gilch/hissp#hebigo
- mumblemumble 5y ago
  This seems a bit like the story with Clojure vis-a-vis Java, to me. Yes, Clojure does a lot to clean up Java's verbosity, flaky implementation of generics, etc. But I don't think that's actually because Clojure is a Lisp; I think it's mostly because Clojure is a dynamic language. For example, Clojure largely resolves Java's generics situation by simply not needing them in the first place. That worked for Java, where a lot of people are stuck on the JVM for legacy reasons, but yearning to at least be able to work in a more ergonomic language. Go lives in a different social environment, though. Nobody's stuck on Go because they've got 25 years' worth of massive legacy Go monoliths that they can't just chuck out the door. They're on Go because Go is what they want. And I'm pretty sure, given that they're invested in Go, that a dynamic language with a heavy focus on metaprogramming is approximately the opposite of what they want.
- mst 5y ago
  I keep meaning to play with https://github.com/cosmos72/gomacro https://github.com/cosmos72/gomacro
lispm 5y ago
It's a Lisp-flavored Python, Python with Lisp syntax. Just doing a syntax translation into an AST might not be enough to implement an actual Lisp on another language.
- mumblemumble 5y ago
  I spent some time with Hy about a year back, and that is approximately the impression I brought away. In order to maintain good interop with Python, they had to make a lot of compromises about how things work in Hy, relative to what a Lisper might expect. The most striking example I can think of offhand is that `let` had to get banished from the standard library: https://github.com/hylang/hy/issues/844 https://github.com/hylang/hy/issues/844 That said, Hy is still a nice language, and very well thought out. It's just that billing it as a lisp dialect for Python (as the project's website does) might lead to some false expectations. That GH thread I linked above is a great example of this. There's a lot of good, careful thought going into the design of the language. But it also has this sentence in the opening comment: "Hy is not Clojure, nor Common Lisp, but homoiconic Python." If you're interested in a Python variant with good macro system, this is it. (Also, I'm not sure it necessarily disqualifies Hy from being a lisp. There are too many different conflicting opinions about the definition of 'lisp' for me to want to say either way, and, while a lot of good and insightful things have been said on the subject, I've personally always found that particular argument to be rather boring.)
  - gilch 5y ago
    Hy does have a let macro now, but you have to (require) it before it works: https://docs.hylang.org/en/master/api.html#module-hy.contrib.walk https://docs.hylang.org/en/master/api.html#module-hy.contrib...
jhgb 5y ago
> Which is how Lisps should be implemented on top of modern environments. Lisps are modern environments. Which is why they're implemented in themselves.

by aasasd 5y ago

kubb 5y ago

The mapping of the AST onto lisp plus an implementation of macros would solve all the issues with Go verbosity, lack of generics, error handling, and probably much more. But it would have a lot of braces so junior programmers wouldn't be able to use it and so it's a non starter.

aasasd 5y ago
You can translate an analogous syntax of your choosing into the same lists =) E.g. something Python-ish or Yaml-ish, or Rebol.
- gilch 5y ago
  See Hebigo's Python-like approach: https://github.com/gilch/hissp#hebigo https://github.com/gilch/hissp#hebigo
mumblemumble 5y ago
This seems a bit like the story with Clojure vis-a-vis Java, to me. Yes, Clojure does a lot to clean up Java's verbosity, flaky implementation of generics, etc. But I don't think that's actually because Clojure is a Lisp; I think it's mostly because Clojure is a dynamic language. For example, Clojure largely resolves Java's generics situation by simply not needing them in the first place. That worked for Java, where a lot of people are stuck on the JVM for legacy reasons, but yearning to at least be able to work in a more ergonomic language. Go lives in a different social environment, though. Nobody's stuck on Go because they've got 25 years' worth of massive legacy Go monoliths that they can't just chuck out the door. They're on Go because Go is what they want. And I'm pretty sure, given that they're invested in Go, that a dynamic language with a heavy focus on metaprogramming is approximately the opposite of what they want.
mst 5y ago
I keep meaning to play with https://github.com/cosmos72/gomacro https://github.com/cosmos72/gomacro

lispm 5y ago

It's a Lisp-flavored Python, Python with Lisp syntax. Just doing a syntax translation into an AST might not be enough to implement an actual Lisp on another language.

mumblemumble 5y ago
I spent some time with Hy about a year back, and that is approximately the impression I brought away. In order to maintain good interop with Python, they had to make a lot of compromises about how things work in Hy, relative to what a Lisper might expect. The most striking example I can think of offhand is that `let` had to get banished from the standard library: https://github.com/hylang/hy/issues/844 https://github.com/hylang/hy/issues/844 That said, Hy is still a nice language, and very well thought out. It's just that billing it as a lisp dialect for Python (as the project's website does) might lead to some false expectations. That GH thread I linked above is a great example of this. There's a lot of good, careful thought going into the design of the language. But it also has this sentence in the opening comment: "Hy is not Clojure, nor Common Lisp, but homoiconic Python." If you're interested in a Python variant with good macro system, this is it. (Also, I'm not sure it necessarily disqualifies Hy from being a lisp. There are too many different conflicting opinions about the definition of 'lisp' for me to want to say either way, and, while a lot of good and insightful things have been said on the subject, I've personally always found that particular argument to be rather boring.)
- gilch 5y ago
  Hy does have a let macro now, but you have to (require) it before it works: https://docs.hylang.org/en/master/api.html#module-hy.contrib.walk https://docs.hylang.org/en/master/api.html#module-hy.contrib...

jhgb 5y ago

> Which is how Lisps should be implemented on top of modern environments. Lisps are modern environments. Which is why they're implemented in themselves.