4 ms·

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

by gopalv 12y 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/compiler.py#L598 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 12y 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/interpreter.py https://github.com/pixie-lang/pixie/blob/master/pixie/vm/int...
srean 12y 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 12y 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.
sedachv 12y 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/ http://benchmarksgame.alioth.debian.org/ no basis for calling it "fast."
- andrewchambers 12y 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.
  - sedachv 12y ago
    You don't understand what the word "native" means. Transpiling to C is not "native." The RPython JIT 'compiler' is a trace optimizer for the bytecode interpreter. There is absolutely nothing "native" about that. If you don't have an assembler, it's not "native."
    - andrewchambers 12y ago
      The trace JIT has an assembler, and the C code is compiled to native assembly. https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d021251770bb5393ee3/rpython/jit/backend/x86/assembler.py https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d02... Assembler.py is the jit assembler.
andrewchambers 12y 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.

by gopalv 12y ago

DasIch 12y 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/interpreter.py https://github.com/pixie-lang/pixie/blob/master/pixie/vm/int...

srean 12y 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 12y 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.

sedachv 12y 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/ http://benchmarksgame.alioth.debian.org/ no basis for calling it "fast."

andrewchambers 12y 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.
- sedachv 12y ago
  You don't understand what the word "native" means. Transpiling to C is not "native." The RPython JIT 'compiler' is a trace optimizer for the bytecode interpreter. There is absolutely nothing "native" about that. If you don't have an assembler, it's not "native."
  - andrewchambers 12y ago
    The trace JIT has an assembler, and the C code is compiled to native assembly. https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d021251770bb5393ee3/rpython/jit/backend/x86/assembler.py https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d02... Assembler.py is the jit assembler.

andrewchambers 12y 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.