Python parsing

[jeremyferguson]

This PR implements Python parsing, which consists of two components:

1. parser.py, which parses a Python AST into an IIR s-expression
2. parse.ml, which translates between s-expressions of the IIR and OCaml instances of the program type, representing an IIR AST. This was written before Kevin found out how to make @@deriving sexp work with the program type, and the core functionality could be replaced by adding these annotations. However, I believe that the functionality gained by using the program_of_sexp functions I wrote is worth the added complexity, as it allows us to write more compact representations of s-expressions, which simplifies writing tests. The current use case that is saving time is due to the custom way that Names are parsed. For example, the expression Call (Name "dot" [Name "x"; Name "y"]) when written out in a string using my implementation is (Call dot x y), whereas the native s-expression parsing would use (Call Name "dot" (Name "x" Name "y")). This is a small example but I believe this can be extended to other primitive type parsing in the future and will simplify test-writing in the long run. Additionally, this PR includes 3 tests for the parsing functionality.

[justinlubin]

Also, I'm fine with custom sexp functions or using @@deriving. We can leave it as-is and migrate in the future if we want, but it definitely looks good to me!

[jeremyferguson]

what does the () on line 1 of test1.sexp represent?

The .sexp files are an s-expression which at the top level is a list with 2 elements. The first element is the env and the second is the block. In the first test case, we don't define any functions, so env is the empty list.

[justinlubin]

The .sexp files are an s-expression which at the top level is a list with 2 elements. The first element is the env and the second is the block. In the first test case, we don't define any functions, so env is the empty list.

Perfect, thanks!