Compiler work

Puffin pair

Double puffin this week! And that's to (partly) make up for my short 3 day vacation to Scotland, starting tomorrow.


I've been working on the compiler, getting it to cooperate and use the object system. Getting it to use my objects wasn't too hard, since I designed the objects for that use in the first place, but many other issues surfaced.


First, my object system isn't just incomplete, but also buggy. I found a few minor bugs and a couple of not so minor bugs, but nothing huge. It appears that overall, it's sound.


Second, PIR is not very nice. Sometimes it's too low-level, often it's too high-level. Almost always it's surprising, and largely because it does in fact have semantics of its own that can't be (easily) overriden. And I've yet to complain about IMCC, which is just dreadful.


Third, it's not entirely clear what namespaces/scopes/frames should be implemented as in parrot. I can't use PIR's .local/.lex since the semantics are wrong for Python. I can't use the NameSpace PMC because it doesn't really work. What I'm doing now is using Python dicts to implement frames, just like CPython. This means a new dict (basically a Hash boxed in a Python.instance) gets created for every module import, function/class declaration, function call, class instantiation, etc. Also, every time any name (symbol) is looked up, at least one Hash lookup is performed.

This is very, very bad for performance. A significant amount of PyPy's JIT's performance comes from just virtualising frames (not creating them unless really needed). But right now, I don't care at all. So I'll likely provide CPython's sys._getframe() without any performance degradation. Instead, there will be a constant performance degradation. Yay!


It's not all bad news, though. AFAICT, I will be able to implement correct Python semantics. There's a lot of work to be done to achieve this, and I doubt I'll be able to do all of it during GSoC, but I see no major obstacles that cannot be at least worked around.


See you on Friday!