Initial RPython codegen

[MostAwesomeDude]

Hi! This codegen backend generates Python 2.7 syntax which is compatible with the RPython toolchain, as used in projects like PyPy and Typhon.

I'm still refining the output. In particular, I haven't gotten anything to translate with RPython properly. So this isn't quite ready to merge. On the other hand, there is at least one bugfix in the synthesis package here.

[MostAwesomeDude]

Hi Calvin! I'm gonna reply inline, but the basic outline:

• This PR as-is is the wrong approach. The biggest problem (besides what you've pointed out) is that, as usual, RPython's type system isn't amenable to quite the shallow encoding that I had imagined. Map<Bag<Int>> is a legal Cozy type, but in RPython, that would require using a dict as a dict key, which isn't legal. I need to probably write an RPython module to give an intermediate Bag wrapper class, at least.
• I think that at least some of the bugfixes are useful, and maybe we can bludgeon this into some more useful shared optimizations in the common IR. I was thinking in particular about smart constructors for statements and some expressions, so that _var1 + [] or for _var1 in [e]; ... aren't even constructed, but I'm not sure whether that interferes with the synthesis/search.
• For the future, I'm still trying to understand handle types and how that works with RPython's reference semantics. RPython, like Java, has a sharp edge between primitive values like 42 and reference values like {}.
• I'm also not sure how mutability works in Cozy. RPython is a warmup (and a gift to my PyPy friends), but I really want to emit Monte code, and Monte's core datastructures (List, Map, Set, the classics) are immutable by default, with opt-in mutability. At least there, I can use any data as map/set keys!

So yeah, let's not merge this, but let's also figure out how to do better next time.

[Calvin-L]

Sounds good! I've cherry-picked your synthesis fix into master.

smart constructors for statements and some expressions

This is already sort-of done in the Java and C++ codegen, where all iterative operations distribute over singletons, appends, etc. It would probably be better to handle those in a separate simplification pass.

I'm also not sure how mutability works in Cozy

Most values are mutable, but there is no aliasing. Two different bag variables are always different bags; changes to one do not affect the other. Pointers (aka handles) are the only exception.

[Calvin-L]

@MostAwesomeDude I closed this PR since you didn't feel confident in it, but I want to reemphasize that I think adding additional backends is a great project.

Are you still planning to continue working on this? Infrastructure to make writing new backends easier would be extremely helpful as well. Your "smart constructors" idea is neat, but I think a lot of those transformations could be done in a pre-codegen simplification pass (#49). It would also help simplify the Java and C++ backends a lot.