A Lisp that runs Python (2016)(kitchingroup.cheme.cmu.edu)
kitchingroup.cheme.cmu.edu
A Lisp that runs Python (2016)
http://kitchingroup.cheme.cmu.edu/blog/2016/03/30/OMG-A-Lisp-that-runs-python/
5 comments
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?
Any suggestions?
> ... 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://docs.racket-lang.org/sweet/index.html
... Or perhaps have a look at Julia:
https://julialang.org/
"Julia - to Lisp or not to Lisp":
https://m.youtube.com/watch?v=dK3zRXhrFZY
[ed: and as mentioned below, there's also wisp:
http://www.draketo.de/english/wisp
]
You might like sweet expressions coupled with a common lisp, a scheme or racket:
http://readable.sourceforge.net/
http://docs.racket-lang.org/sweet/index.html
... Or perhaps have a look at Julia:
https://julialang.org/
"Julia - to Lisp or not to Lisp":
https://m.youtube.com/watch?v=dK3zRXhrFZY
[ed: and as mentioned below, there's also wisp:
http://www.draketo.de/english/wisp
]
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.
You could just write your own `read` that supports indentation instead of brackets. It would be pretty annoying, though.
Yes, 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/...
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...
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...
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-parent...
Right at this moment I'm reading this paredit guide : http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
Right at this moment I'm reading this paredit guide : http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
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.
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.
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.
Not unlike Lisp Flavored Erlang, which is a Lisp atop Erlang's BEAM virtual machine and that compiles into pure Erlang.
I thought it compiled to BEAM bytecode, is that wrong?
(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.
Someone correct me if I've got that wrong.
If I'm reading this[0] correctly, it looks like you're right.
[0]: https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.er...
[0]: https://github.com/rvirding/lfe/blob/develop/src/lfe_comp.er...
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.
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.
Maybe burgled-batteries, which relies on CPython (https://github.com/pinterface/burgled-batteries).
Thanks! You made my day!!
And the "burgled-batteries" name was a good laugh! (If Python is "batteries included", let's steal those batteries!)
And the "burgled-batteries" name was a good laugh! (If Python is "batteries included", let's steal those batteries!)
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
Is that just an enormous tuple?
There is also this: https://github.com/metawilm/cl-python
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.
IIRC, it still uses Python's weird ideas of scope. That is to say, no.
> 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?
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?
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.
However, allowing block scope variables would make the interpreter internals far more complex for dubious benefit.
There's nothing weird about closure-based scoping. You find this in Python, R, Javascript, ... It has roots in the lambda calculus.
"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".