Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixie: A small fast, native lisp

github.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Pixie: A small fast, native lisp

#31

Post by sktatlo »

_halgari wrote: post #27

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!

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?

Re: Pixie: A small fast, native lisp

#32

Post by lispm »

sklogic wrote: post #24
wtbob wrote: post #22

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

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.

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.

Re: Pixie: A small fast, native lisp

#33

Post by _halgari »

sktatlo wrote: post #31
_halgari wrote: post #27

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!

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?

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.

Re: Pixie: A small fast, native lisp

#34

Post by wtbob »

sklogic wrote: post #24
wtbob wrote: post #22

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

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.

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.

Re: Pixie: A small fast, native lisp

#35

Post by emidln »

_halgari wrote: post #33
sktatlo wrote: post #31

Earlier quoted context omitted.

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?

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 actuall…

It might be interesting down the line to see if I couldn't target pixie using something like cljx (or actual feature expressions if they ever land in a mainline clojure release). This wouldn't necessarily require any effort on the part of my target, but still allow portability when it makes sense.

Re: Pixie: A small fast, native lisp

#36

Post by JasonFruit »

dTal wrote: post #17
616c wrote: post #8

Earlier quoted context omitted.

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.

One problem with Hy for me is that it keeps Python scoping, either global or function; that doesn't feel natural to me in a Lisp, and it gets in my way. If it weren't for that and a few similar matters, I'd agree with you on Hy's practicality; as it is, I'd give my nod to Clojure.

Re: Pixie: A small fast, native lisp

#37

Post by sedachv »

sklogic wrote: post #24
wtbob wrote: post #22

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

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.

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

Re: Pixie: A small fast, native lisp

#38

Post by sedachv »

gopalv wrote: post #9

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

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

Re: Pixie: A small fast, native lisp

#39

Post by andrewchambers »

_halgari wrote: post #27

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!

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

Re: Pixie: A small fast, native lisp

#40

Post by andrewchambers »

sedachv wrote: post #38
gopalv wrote: post #9

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

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

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.
Post reply on HN