
A Lisp that runs Python (2016) - malloryerik
http://kitchingroup.cheme.cmu.edu/blog/2016/03/30/OMG-A-Lisp-that-runs-python/
======
rntz
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
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?

~~~
todd8
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
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.

------
flavio81
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
Maybe burgled-batteries, which relies on CPython
([https://github.com/pinterface/burgled-
batteries](https://github.com/pinterface/burgled-batteries)).

~~~
flavio81
Thanks! You made my day!!

And the "burgled-batteries" name was a good laugh! (If Python is "batteries
included", let's steal those batteries!)

------
twic
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
Is that just an enormous tuple?

------
e40
There is also this: [https://github.com/metawilm/cl-
python](https://github.com/metawilm/cl-python)

------
paultopia
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
IIRC, it still uses Python's weird ideas of scope. That is to say, no.

~~~
NoahTheDuke
> 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
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.

