The author is the creator of clojure-py [1]. Pixie looks like a follow-up effort with strong influence from PyPy. The following post of his from over 2 years ago might provide some insight: https://groups.google.com/forum/#!topic/clojure-py-dev/Lmhd0...
Pixie: A small fast, native lisp
11–20 of 58 posts
Re: Pixie: A small fast, native lisp
#12This is a lisp engine written in python - RPython, to be precise. It literally compiles the lisp code into python bytecode, which is pretty neat - sort of like clojure is for the JVM. https://github.com/pixie-lang/pixie/blob/master/pixie/vm/com... Perhaps not magical, but I like the effort (though lisp-as-shell has to contend with emacs first).
It compiles to bytecode but it doesn't compile to python bytecode. The bytecode used by pixie is custom and also interpreted by pixie itself[1].
[1]: https://github.com/pixie-lang/pixie/blob/master/pixie/vm/int...
Re: Pixie: A small fast, native lisp
#13This is a lisp engine written in python - RPython, to be precise. It literally compiles the lisp code into python bytecode, which is pretty neat - sort of like clojure is for the JVM. https://github.com/pixie-lang/pixie/blob/master/pixie/vm/com... Perhaps not magical, but I like the effort (though lisp-as-shell has to contend with emacs first).
Ever since RPython had been announced I have wanted generator support in RPython. TCO'ed coroutines would be even better. PyPy devs did not see much use of it for writing their Python interprator so they left it out, which is a pity.
How so ever shiny and neat dynamic typing might be, I have had very little use of it in my own Python code. A situation where I absolutely must store values of different types in the same variable (that or bullet to the head) has not presented itself that often if ever. For me RPython would have been a fine enough replacement, except that I do like generators a lot.
Given the prominence of inversion of control (via coroutines) as a feature, I assume it would have helped pixie implementation too.
Re: Pixie: A small fast, native lisp
#14I love little languages like this one! Just look at the source — it's still so readable and easy to understand, and the size — I could read through it in an evening!
It reminds me a bit of diy-lisp where you implemented Lisp in Python yourself! https://github.com/daGrevis/diy-lisp
Re: Pixie: A small fast, native lisp
#15Earlier quoted context omitted.
The magical lack of documentation?
There are 61 commits and only one contributor. This isn't a good complaint, and the snark makes it worse.
The snark wasn't necessary indeed, and as an early-stage project, lacking documentation is understandable.
As an HN post however, if you tease us with "magical features" in the title, I'd expect to have the magic shown to me in the linked page, or at the very least in the top comment. I shouldn't have to grok the sources to figure it out.
Re: Pixie: A small fast, native lisp
#16This is a lisp engine written in python - RPython, to be precise. It literally compiles the lisp code into python bytecode, which is pretty neat - sort of like clojure is for the JVM. https://github.com/pixie-lang/pixie/blob/master/pixie/vm/com... Perhaps not magical, but I like the effort (though lisp-as-shell has to contend with emacs first).
Ever since RPython had been announced I have wanted generator support in RPython. TCO'ed coroutines would be even better. PyPy devs did not see much use of it for writing their Python interprator so they left it out, which is a pity. How so ever shiny and neat dynamic typing might be, I have had very little use of it in my own Python code. A situation where I absolutely must store values of different types in the sam…
RPython is not a language for normal usage and mostly because e.g. error messages are obscure and hard to read. There is some basic support for generators these days, however, unless you're writing another language, we strongly encourage you don't use it.
Re: Pixie: A small fast, native lisp
#17What's magical about it?
Well judging from the description, "native" actually means writing it in RPython (a "restricted" Python with types for use in the PyPy Project for static analysis and speeding things up[0]) and then compiling it down using PyPy (I am guessing on the second part). That could be neat, the HyLang people (Lisp written in vanilla CPython Python; I think no C extensions AFAIK). [0] http://pypy.readthedocs.org/en/latest/cod…
Hy isn't a full Lisp interpreter in Python, it's an s-expression to Python AST parser, which means it does everything Python does (including C extensions) at essentially native speed anyway - you can even write RPython in it.
If you ask me, full Python interop makes Hy the most practical s-expression language today.
Re: Pixie: A small fast, native lisp
#18I'm happy to see that some new 'modern lisp on x' projects are taking design cues from Clojure (See Rhine and now Pixie).
Clojure's success, I believe, is due to retaining Java's semantics (preserving library compatibility) while overhauling its syntax. Fighting the semantics of your host language/VM just makes work and causes trouble. Therefore, if you want a "Clojure on Python" that preserves the benefits of the original, you need to give it Python semantics, not Java/Clojure's. Hylang is that project - it uses Clojure syntax where sensible, and is fully compatible with Python.
https://groups.google.com/forum/#!topic/clojure-py-dev/HbeNE...
Re: Pixie: A small fast, native lisp
#19Earlier quoted context omitted.
The magical lack of documentation?
There are 61 commits and only one contributor. This isn't a good complaint, and the snark makes it worse.
Thanks, i already noticed the age of the project :). The ""complaint"" is obviously valid, i'd add at least half a page of examples to explain what it does and how to try it, just to increase the chance of contribution.
No snarkiness was intended... but looks like it came out that way.
Re: Pixie: A small fast, native lisp
#20What's magical about it?
Added a few comments in the README about that.