I saw Hy pop up a week or so ago and I've decided to give it a serious spin since I've always wanted to learn a Lisp but never wanted to learn a whole new eco-system.
It's been phenomenal so far and I want to finish my comment the same way the author finishes his blog post:
> It stands on the shoulders of a giant (Python) and balances another giant (Lisp) on top of this. Better is better, guys. pip install hy.
More seriously, is Hy anything more than writing Python with some parentheses there and there?
Coding in Lisp has nothing to do with putting parentheses everywhere but rather with thinking in some specific way. For instance, I know that I am ready to code something in Lisp when I see my whole task as a sequence of CONS, but how could Hy truly implement such a thing as long as it relies on Python lists?
I played with it a bit, it's homoiconic, has macros, and papers over the difference between Python statements and expressions (so that everything is expressions).
That's sort of the point. It's "just Python". It's s-expression syntax for Python.
Why would one want such a thing? Well, s-expressions confer many advantages (and of course, some disadvantages - it's good to have a choice!)
- It makes it easy to write code that writes code, which is useful because it affords "compile-time" abstractions with no runtime performance penalty (in lisp terms, "macros").
- If you're comfortable with a structure editor, it enormously lowers the friction involved in refactoring.
- It allows everything to be an expression:
json.loads(with f as open("file.json"): f.read()) #doesn't work
(json.loads (with [f (open "file.json")] (f.read))) ;works
- It effectively removes all restrictions based around things fitting on a single line - lambdas are the canonical example.
(Hell is debugging someone else's LISP macros. I have a very old LISP program, a theorem prover, I've tried to convert from Franz LISP, a Maclisp dialect, to Common LISP. I worked on it years ago. I just can't fix some of the bugs. The original authors of the part that doesn't work right are long dead.)
I went down this path until I tried to run pdb or profilers on mixed language stuff, result was not great.
Python is already fairly OK, use decorators instead of def macro, metaclasses if you need to get into head-scratching territory etc. Use the 4 argument form of the type function, belabor __new__ etc it will still be readable instead of a pile of nail clippings
I've used both, and a big difference is that the normal Python tools work for metaclasses, but I'm not sure if you can do step through debugging of a macro?
Hy is what got me into lisp dialects and parted the clouds on the bliss of simplicity of the syntax and made me see that I had been living like a savage with C-style languages and OO slavery.
Give it a try! It is really fun and significantly lowers the barrier off entry to the land of lisp!
If you are talking about the import hooks, I think those require the imported file to have valid python syntax. The import hooks work on the python AST (I think)
As I recall, patching was simply the most expedient approach. Otherwise, for the changes we needed to make, we would've had to copy a lot of source from the standard loader implementation in CPython for only a few simple changes.
It's been phenomenal so far and I want to finish my comment the same way the author finishes his blog post:
> It stands on the shoulders of a giant (Python) and balances another giant (Lisp) on top of this. Better is better, guys. pip install hy.