Pixie: A small fast, native lisp

by emidln • 12 years ago

103 49 12 years ago

GuiA• 12 years ago

What's magical about it?

I'm wondering the same thing. I dug through the entire repository, and I didn't see any references to "magical" properties.

andrewchambers8• 12 years ago

Did you look through the rpython codebase too? Thats where the real magic is.

616c• 12 years ago

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/coding-guide.html#id1

dTal3• 12 years ago

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.

_halgari5• 12 years ago

Added a few comments in the README about that.

daveloyall• 12 years ago

Pixie implements its own virtual machine.

Isn't that how all the tiny lisps do it? :)

You know, maybe 'magic' simply sets the bar higher than the project is prepared to support. Consider 'clever'.

ottbot• 12 years ago

Have fun.

nicklovescode• 12 years ago

Would love some examples that showoff the benefits

_halgari5• 12 years ago

I added a few comments to the README on that subject.

gopalv• 12 years ago

This 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).

DasIch• 12 years ago

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

srean• 12 years ago

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.

fijal• 12 years ago

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.

sedachv5• 12 years ago

This is a lisp engine written in python - RPython, to be precise.

So there is nothing "native" about it, and until we see this on http://benchmarksgame.alioth.debian.org/ no basis for calling it "fast."

andrewchambers8• 12 years ago

You don't understand what rpython is. RPython is a statically typed subset of python which compiles to C. It also has code in it for generating a Jit.

andrewchambers8• 12 years ago

You have misunderstood. Rpython compiles to C and then to a binary. There is no python bytecode there. Only pixie bytecode being interpreted by the compiled binary.

It also has a Jit engine inside it.

cryptolect• 12 years ago

I'm happy to see that some new 'modern lisp on x' projects are taking design cues from Clojure (See Rhine and now Pixie).

dTal3• 12 years ago

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

http://hy.readthedocs.org/en/latest/

andrewchambers8• 12 years ago

Only hylang has a lot of stupid limitations and problems like scope leakage.

eddieplan9• 12 years ago

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

[1] https://news.ycombinator.com/item?id=3649883

daGrevis• 12 years ago

I 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

wtbob2• 12 years ago

It looks cool enough, but I wish more of these modern Lisp implementations would ask to implement the Common Lisp standard rate than their own, informally-specified version of Lisp. Yeah, Common Lisp is not perfect, but it does have a lot of excellent ideas, and some of the bits which don't look excellent actually are (e.g. pathnames and logical pathnames).

sklogic5• 12 years ago

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

lispm• 12 years ago

Depends on what you mean by 'big'. Physically it is not too big for typical applications. 'mentally' it may be too big for some developers. After a while then greenspun's tenth rule kicks in...

'Common Lisp' also does not mean it needs the full language. Some applications use subsets.

wtbob2• 12 years ago

I know folks used to say that Common Lisp was too big, comparing it to C or Pascal. But is it really big compared to, e.g., Python, JavaScript or Ruby? If anything, a common complaint now is that too little is standardised (which is true, but good portable libraries exist for most such things).

And, as lispm notes, one can implement a subset of Common Lisp—all that's required is that one define the subset.

sedachv5• 12 years ago

And it's a Lisp-2, which is quite a deterrent for many.

I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.

lsdafjklsd• 12 years ago

Neat project, although I am struggling with getting it working. Looking forward to installation instructions.

_halgari5• 12 years ago

Author of pixie here. The project is still pretty young (about a month old), so I'll use that to explain away the lack of binaries, documentation, examples, etc. I've been more focused on adding features than getting stuff ready for presenting to the public. As an example, we didn't even have stack traces until a day or two ago.

That being said I'll try to answer any questions you may have. Thanks!

sktatlo• 12 years ago

This is an amazing effort! Now to clojure compatibility. You can only gain by making it clojure compatible. What would be the possible reasons to diverge? Another one: what are your plans for namespaces and code packaging and distribution? What are your thoughts about a build system? I think the world doesn't need another build and package distribution system. Which one would you reuse?

_halgari5• 12 years ago

I love clojure, let me make this clear. But there are certain aspects of the language that don't apply if you are writing a VM from scratch in RPython. If I could make multimethods dispatching on types as fast as protocols, what is the point of protocols?

A great example of this is the (fn [& args]) bit. In Clojure, variadic parameters are passed in as a ISeq. In Pixie they are a vector (or an immutable array actually). This allowed me to tune the JIT quite a bit to allow it to remove the allocation of "args" completely. As well as allow for things like unrolling a reduce over the args. This stuff would have been much harder if the arguments were passed in as an ISeq.

This is the whole reason why Pixie exists, instead of something like "clojure-on-rpython". Compatibility means constraining the feature set. And that's not something I want to do yet.

andrewchambers8• 12 years ago

Please be sure to improve on the state of clojure error messages. It would help a lot.

duckingtest• 12 years ago

Math system is fully polymorphic

Does it have fully polymorphic other basic functions, like setq, eql (or however they are named)? I guess not? Do you plan on introducing some parts of CLOS?

Lack of OO integration in CL is one of its biggest drawback for me... for me CLOS was the most powerful thing in lisp, not macros (mostly because they are not dynamic).

_halgari5• 12 years ago

CLOS has been on my list to research for some time now, and I haven't made a decision on it yet. The goal would be to get the JIT to remove the method lookup completely, and that might get a bit tricky depending on how complex the lookup code is, but it is the most open dynamic OO system I've seen, so it might just be worth it.

andrewchambers8• 12 years ago

I'm glad there will be something like clojure, only with semi sane start up times. (pypy based interpreters are still slow to start.)

Pixie: A small fast, native lisp

Related Stories