Pypy Threw My Projects Bottom-Up
In the beginning of this week, I read Laurence Tratt's Fast VM -post. Since then it's been an understatement to say that I am excited about the pypy. Tratt's posts are overall interesting reading.
I worked on for months in solid and the snakelisp -projects. Using Pypy I have already gotten beyond goals of these projects. Compared to what I can get done with RPython, continuing these projects and using C would be pointless.
Pypy offers unforeseeable succinctness for a language designer:
- No header files to write
- No types to type
- Optional memory management, this is invaluable as many memory layouts aren't that important. Needing an another data structure won't put you split your hair.
- Many constructs are generated by the compiler, or by your code, rather than by you.
RPython treats the whole program as a single unit, producing gruesome and difficult error reports. I've experienced a difference to java/C/C++ type systems i can't really explain. It's a harder puzzle with larger rewards: Figuring out why the error happened provides an insight of the program. Apparently static typing may actually do interesting things without those type annotations.
You can test your program in pypy. RPython won't run everything pypy cans, so occassionally you have to compile. I'm happy to how the compiler ignores all the code not reachable in runtime. For some reason it takes 80 seconds for rpython to compile my project. Some task called "database_c" spends half of that time.
Before pypy I considered for tradeoffs, such as imitating well known interpreters. Now I can afford to design things properly, with benchmarks and experiments leading every feature. I still expect early articulate syntax to be a pathway to bikeshedding. I'm sticking to really canonical form of lisp until I am informed enough to give the language a great syntax.
I've looked into other pypy.rpython -projects: Pixie and Trifle Lisp. The experience has been enjoyable. I found the exact things I'm interested about and studied how they work in these projects. In the Pixie I found a memory overflow bug in it's FFI. It's sales pitch seem to rely heavily to the features provided by Pypy.
Trifle seems bit wretched. There's a bookshelf of documentation, with only few sample programs. In the goals it attempts to minimize non-trifle code. A questionable goal considering rpython isn't that horrible. It would help in self-hosting the language, but there are no mentions of that. They ignore idea of compiling to javascript. Yet evaluating untrusted code might be worth some thought. They also say ignoring the problem of interfacing with C but RPython did that lot less difficult than it used to be in interpreter projects.
In both projects I have to consider rpython as an enabling force. Even with their flaws, these projects would exist in much lesser form without it. I am glad about these projects, and rpython's influence on them. They present humongous increase of mobility and potential.
My latest project is pyllisp. The name has etymology on how much bottom-up the pypy threw me. The goal was to study which kind of interpreter would perform best for my language. Since then scope has been expanded. I'm trying out some ideas for an FFI, experiment with different forms of interactive programming. Looking for unique semantics and their effect to coding. I'm doing that because now I can.
I'll make sure my language will support abstract interpretation of it's bytecode, out of the box.