[ANN] A PureScript Python Backend

Announcements
3

Hi, thanks for your kind words!

Have you considered having it output more standard looking python as an option?

This is an interesting question, and the answer is no. I can give you strong reasons why I use pysexpr, in following two respects:

  1. Currently we can directly use some techniques to generate Python-like source code from Python code objects, for example, variable res here is a Python code object. Generating standard Python code is not a hard task.

  2. Generating Python source code will lead to some unnecessary problems, such as

    • Name collisions: Python keywords, and $ or . cannot be used as Python identifiers in source code level. We can see PureScript did a lot of stuffs dealing with name collisions, but for this Python backend, we don’t have to, which makes maintainence easier.

    • Lack of expression-first: Python is statement-first, which is to say, statements definitely cannot occur in expressions, hence Python cannot have block expressions, and no assignment expressions before Python 3.8. Finally, code generation for constructs like while or block becomes very difficult, as we have to transform programs to applicative normal programs to translate expression-first programs to statement-first programs. This workaround has some further drawbacks, see section drawbacks of ANF transformations below.

    • Cross-version support of Python. PySExpr is actually cross-version, and supporting all Python 3 versions used industrially(>=Python3.5). To make the Python source code cross-version, we have to use Python 3.5 only syntax, which means that some optimized Python VM instructions cannot be leveraged, such as FORMAT_VALUE for building interpolation strings much faster, and generating indirect jump instructions to greatly optimize pattern matching.

    • Runtime error reporting linked to purescript source code, which is impossible if you directly generate Python source code. Basically this is what I think to be most important.
      This will give your very intuitive response when implementing FFIs(as FFI itself could be unsafe and produce runtime errors), and support many many wonderful debuggers(like PyCharm, pdb, etc.). A major reason that Haskell annoyed me is, no industrial debugger available, and causing verbose use of Debug.Trace. I want to use some debugger tools to step over/in/out, etc…

P.S: drawbacks of ANF transformations

This will produce unavoidable performance hits, check the code for a comparison between expression-first and statement-first in this post of mine, and the key comments are extracted here:

and you shall do optimizations including register reallocations to avoid using too many extra variables(variables not defined by users, but needed for gaining expression-first). Further, even if you apply many awesome optimizations, limited by the weakness of Python ASTs, you cannot still avoid redundant register allocations, while PySExpr via bytecode approach totally ends this problem.

2 Likes