Berp is an implementation of Python 3. At its heart is a translator, which takes Python code as input and generates Haskell code as output. The Haskell code is fed into a Haskell compiler (GHC) for compilation to machine code or interpretation as byte code.

This project sounds interesting. Has anyone checked it out?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What is the benefit of doing

What is the benefit of doing this?

Well, it substantially

Well, berp substantially outperforms CPython on a few toy benchmarks, although nobody really knows which is "faster" at this point in time. I would imagine that both implementations have a number of performance problems yet to be discovered.


It would be nice if berp is competitive with CPython. I haven't spent much effort on benchmarking yet because the code is immature. I'm hoping that there are some gains to be had in the area of multi-threaded concurrency, where CPython is limited by the global interpreter lock (GIL).

One important question is how to balance completeness with performance. There are certain features of Python which are tricky to implement using the translation scheme currently employed in berp, such as the eval() primitive. I originally conceived of a scheme that would make such things easier, but would be much slower to execute. Essentially it would be more interpreted and less compiled. I agonised over the question of completeness against performance for some time. In the end I decided to try something which might have better performance at the possible expense of completeness. I figured that this might actually bring something new to the table. Having said that, I do want to make it fairly complete, otherwise it wouldn't be very useful.

What is the benefit of doing this?

I've written up some short notes on my motivation for starting this project:

motivation for berp (on github wiki)

It touches on my personal reasons for doing it and also some speculative ideas on technical merit (pros and cons). Whether the speculation turns out to be true is yet to be seen.

I expect others will have their own thoughts on the matter, and I'm happy to discuss in more detail.

Just Forget Eval

If you could implement "Python-minus-eval" while maintaining full FFI compatibility (C libraries, etc.) on the major platforms, many folks would gladly forgo "eval" for access to concurrent execution capabilities. Also any possible type inference to increase performance of compiled code would be a minor god send. (Although all together, sounds like lots of work.)