9 ms·

A Lisp that runs Python (2016)

81 points by malloryerik 9y ago

rntz 9y ago
This article is about Hy, http://docs.hylang.org/en/stable/ http://docs.hylang.org/en/stable/ "A Lisp that runs Python" is kind of vague. Hy describes itself as "a Lisp-flavored Python". I'd call it "a lisp that compiles to Python".
- CoolGuySteve 9y ago
  Hmmm that's too bad, I'd like a python-flavoured lisp. That is a relatively fast functional language that replaces most of the brackets with indentation. Any suggestions?
  - cup-of-tea 9y ago
    You could just write your own `read` that supports indentation instead of brackets. It would be pretty annoying, though.
  - anon90556382956 9y ago
    Yes, wisp : http://www.draketo.de/english/wisp http://www.draketo.de/english/wisp But most lisper prefer parentheses. As for me I'm just starting to learn scheme because of GuixSD and I'm trying to get used to parentheses. It's not that bad if you use paredit/parinfer/...
    - prophesi 9y ago
      Have you used wisp? I'm actually just about to work on a small github project to learn it, and was wondering if there's an editor with wisp syntax highlighting out there. I tend to use VS Code, but it just has a plugin package named "wisp" with no documentation, looks for ".w" extensions, and is on version 0.0.1...
      - anon90556382956 9y ago
        No, I'm just starting to learn my first lisp. I just found wisp while I was lurking on search engines for this parentheses "problem" (as I viewed it). Then I found this answer on quora and started to convince myself parentheses don't really matter: https://www.quora.com/Would-it-be-possible-to-replace-parentheses-in-LISP-with-whitespace https://www.quora.com/Would-it-be-possible-to-replace-parent... Right at this moment I'm reading this paredit guide : http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
  - todd8 9y ago
    Make sure you use an editor, like emacs, that really understands lisp and the parentheses won’t mater. The auto indenting with lisp makes working with it syntactically just as easy as python.
    - CoolGuySteve 9y ago
      I don't disagree, I did that back in university. My problem with the brackets is that it lends itself to a 'write-once-read-never' style when a function ends with 12 round brackets. I think S-expr trees and their macros are the right way to write code, and that a S-expr diff is the one true way to do git-diff. But so far I haven't seen a language that integrates into the toolchain like that. Go has gofmt that at least acknowledges that style should be consistent, but I would argue 'who gives a fuck'. The expression tree is what really matters.
  - macco 9y ago
    Look into pyret. Its made by one of the racket creators. But as most commentors said use a lisp with a good editor. Emacs or atom with parinfer for example.
  - e12e 9y ago
    > ... a relatively fast functional language that replaces most of the brackets with indentation. You might like sweet expressions coupled with a common lisp, a scheme or racket: http://readable.sourceforge.net/ http://readable.sourceforge.net/ http://docs.racket-lang.org/sweet/index.html http://docs.racket-lang.org/sweet/index.html ... Or perhaps have a look at Julia: https://julialang.org/ https://julialang.org/ "Julia - to Lisp or not to Lisp": https://m.youtube.com/watch?v=dK3zRXhrFZY https://m.youtube.com/watch?v=dK3zRXhrFZY [ed: and as mentioned below, there's also wisp: http://www.draketo.de/english/wisp http://www.draketo.de/english/wisp ]
- phoe-krk 9y ago
  Not unlike Lisp Flavored Erlang, which is a Lisp atop Erlang's BEAM virtual machine and that compiles into pure Erlang.
  - fasquoika 9y ago
    I thought it compiled to BEAM bytecode, is that wrong?
    - s_kilk 9y ago
      (From memory, don't quote me on this), The BEAM bytecode is apparently not well documented, so the standard practice for compile-to-beam languages is to emit Erlang terms, then use the erlang toolchain to compile down to bytecode. I think that's how Elixir and LFE do it anyways. Someone correct me if I've got that wrong.
      - fasquoika 9y ago
        If I'm reading this[0] correctly, it looks like you're right. [0]: https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.erl#L486 https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.er...
paultopia 9y ago
Has Hy gotten the let special form working yet? Last I looked, there was a ton of conversation over let not working right/at all, which seems like a big sticking point.
- JasonFruit 9y ago
  IIRC, it still uses Python's weird ideas of scope. That is to say, no.
  - NoahTheDuke 9y ago
    > Python's weird ideas of scope I don't know that I'd call them weird, just the natural result of Python's assignment syntax (tho I suspect that you might call that weird as well). Without specific declaration syntax, it would be somewhere between messy and impossible to differentiate between block and function-level scopes. The only thing I could think of would be the inclusion of a new declaration/assignment operator, like `=:`, that would declare the variable as block scoped, but such a change would be backwards incompatible and I don't believe they're going to do that again. What would you like it to look like? How would you want it to work?
    - xapata 9y ago
      Many choices for a new operator would not cause backwards incompatibility, as it'd currently be invalid syntax. However, allowing block scope variables would make the interpreter internals far more complex for dubious benefit.
  - lionel- 9y ago
    There's nothing weird about closure-based scoping. You find this in Python, R, Javascript, ... It has roots in the lambda calculus.
flavio81 9y ago
The only problem is that everytime he/she wants to execute Hy (Python in s-expression syntax) code, he will invoke the macro "org-babel-execute:hy", and this runs Hy as a shell command. So Common Lisp objects can't be quickly copied or shared to Python, and for each invocation there is a time overhead. I'd love to see a good bridge from Common Lisp to Python. It should be possible.
- junke 9y ago
  Maybe burgled-batteries, which relies on CPython (https://github.com/pinterface/burgled-batteries https://github.com/pinterface/burgled-batteries).
  - flavio81 9y ago
    Thanks! You made my day!! And the "burgled-batteries" name was a good laugh! (If Python is "batteries included", let's steal those batteries!)
e40 9y ago
There is also this: https://github.com/metawilm/cl-python https://github.com/metawilm/cl-python
twic 9y ago
Meanwhile, at the shallow end of the meme pool, this gem from back in the day - a LISP interpreter in a single Python expression: http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html
- nerdponx 9y ago
  Is that just an enormous tuple?

81 points by malloryerik 9y ago

rntz 9y ago

This article is about Hy, http://docs.hylang.org/en/stable/ http://docs.hylang.org/en/stable/ "A Lisp that runs Python" is kind of vague. Hy describes itself as "a Lisp-flavored Python". I'd call it "a lisp that compiles to Python".

CoolGuySteve 9y ago
Hmmm that's too bad, I'd like a python-flavoured lisp. That is a relatively fast functional language that replaces most of the brackets with indentation. Any suggestions?
- cup-of-tea 9y ago
  You could just write your own `read` that supports indentation instead of brackets. It would be pretty annoying, though.
- anon90556382956 9y ago
  Yes, wisp : http://www.draketo.de/english/wisp http://www.draketo.de/english/wisp But most lisper prefer parentheses. As for me I'm just starting to learn scheme because of GuixSD and I'm trying to get used to parentheses. It's not that bad if you use paredit/parinfer/...
  - prophesi 9y ago
    Have you used wisp? I'm actually just about to work on a small github project to learn it, and was wondering if there's an editor with wisp syntax highlighting out there. I tend to use VS Code, but it just has a plugin package named "wisp" with no documentation, looks for ".w" extensions, and is on version 0.0.1...
    - anon90556382956 9y ago
      No, I'm just starting to learn my first lisp. I just found wisp while I was lurking on search engines for this parentheses "problem" (as I viewed it). Then I found this answer on quora and started to convince myself parentheses don't really matter: https://www.quora.com/Would-it-be-possible-to-replace-parentheses-in-LISP-with-whitespace https://www.quora.com/Would-it-be-possible-to-replace-parent... Right at this moment I'm reading this paredit guide : http://danmidwood.com/content/2014/11/21/animated-paredit.html http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
- todd8 9y ago
  Make sure you use an editor, like emacs, that really understands lisp and the parentheses won’t mater. The auto indenting with lisp makes working with it syntactically just as easy as python.
  - CoolGuySteve 9y ago
    I don't disagree, I did that back in university. My problem with the brackets is that it lends itself to a 'write-once-read-never' style when a function ends with 12 round brackets. I think S-expr trees and their macros are the right way to write code, and that a S-expr diff is the one true way to do git-diff. But so far I haven't seen a language that integrates into the toolchain like that. Go has gofmt that at least acknowledges that style should be consistent, but I would argue 'who gives a fuck'. The expression tree is what really matters.
- macco 9y ago
  Look into pyret. Its made by one of the racket creators. But as most commentors said use a lisp with a good editor. Emacs or atom with parinfer for example.
- e12e 9y ago
  > ... a relatively fast functional language that replaces most of the brackets with indentation. You might like sweet expressions coupled with a common lisp, a scheme or racket: http://readable.sourceforge.net/ http://readable.sourceforge.net/ http://docs.racket-lang.org/sweet/index.html http://docs.racket-lang.org/sweet/index.html ... Or perhaps have a look at Julia: https://julialang.org/ https://julialang.org/ "Julia - to Lisp or not to Lisp": https://m.youtube.com/watch?v=dK3zRXhrFZY https://m.youtube.com/watch?v=dK3zRXhrFZY [ed: and as mentioned below, there's also wisp: http://www.draketo.de/english/wisp http://www.draketo.de/english/wisp ]
phoe-krk 9y ago
Not unlike Lisp Flavored Erlang, which is a Lisp atop Erlang's BEAM virtual machine and that compiles into pure Erlang.
- fasquoika 9y ago
  I thought it compiled to BEAM bytecode, is that wrong?
  - s_kilk 9y ago
    (From memory, don't quote me on this), The BEAM bytecode is apparently not well documented, so the standard practice for compile-to-beam languages is to emit Erlang terms, then use the erlang toolchain to compile down to bytecode. I think that's how Elixir and LFE do it anyways. Someone correct me if I've got that wrong.
    - fasquoika 9y ago
      If I'm reading this[0] correctly, it looks like you're right. [0]: https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.erl#L486 https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.er...

paultopia 9y ago

Has Hy gotten the let special form working yet? Last I looked, there was a ton of conversation over let not working right/at all, which seems like a big sticking point.

JasonFruit 9y ago
IIRC, it still uses Python's weird ideas of scope. That is to say, no.
- NoahTheDuke 9y ago
  > Python's weird ideas of scope I don't know that I'd call them weird, just the natural result of Python's assignment syntax (tho I suspect that you might call that weird as well). Without specific declaration syntax, it would be somewhere between messy and impossible to differentiate between block and function-level scopes. The only thing I could think of would be the inclusion of a new declaration/assignment operator, like `=:`, that would declare the variable as block scoped, but such a change would be backwards incompatible and I don't believe they're going to do that again. What would you like it to look like? How would you want it to work?
  - xapata 9y ago
    Many choices for a new operator would not cause backwards incompatibility, as it'd currently be invalid syntax. However, allowing block scope variables would make the interpreter internals far more complex for dubious benefit.
- lionel- 9y ago
  There's nothing weird about closure-based scoping. You find this in Python, R, Javascript, ... It has roots in the lambda calculus.

flavio81 9y ago

The only problem is that everytime he/she wants to execute Hy (Python in s-expression syntax) code, he will invoke the macro "org-babel-execute:hy", and this runs Hy as a shell command. So Common Lisp objects can't be quickly copied or shared to Python, and for each invocation there is a time overhead. I'd love to see a good bridge from Common Lisp to Python. It should be possible.

junke 9y ago
Maybe burgled-batteries, which relies on CPython (https://github.com/pinterface/burgled-batteries https://github.com/pinterface/burgled-batteries).
- flavio81 9y ago
  Thanks! You made my day!! And the "burgled-batteries" name was a good laugh! (If Python is "batteries included", let's steal those batteries!)

e40 9y ago

There is also this: https://github.com/metawilm/cl-python https://github.com/metawilm/cl-python

twic 9y ago

Meanwhile, at the shallow end of the meme pool, this gem from back in the day - a LISP interpreter in a single Python expression: http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html

nerdponx 9y ago
Is that just an enormous tuple?