[BiteCode_dev]

> We've currently got proof of concept implementations for Lisp and Python

So what would be the benefit over something like http://hypothesis.readthedocs.io ?

From the look of it (the mention of "free" on the website), you have some monetization in mind. What form would that take?

[Choc13]

I’ve not used Hypothesis, but says it’s inspired by QuickCheck and I’m a regular user of FsCheck which is the F# equivalent. Those tools have a similar goal in mind that we do, but whereas they generate randomised test data (I think FsCheck creates 100 test cases IIRC), we effectively solve the equation so we can actually say that it holds for all inputs. The key difference is that we don’t actually invoke the code with concrete values, but rather treat it like a set of constraints that should always be satisfied. We then check these constraints and if they fail we can reverse engineer a concrete value that would cause the violation. So we effectively run it for all inputs, without actually running it for any inputs.

[Choc13]

On the monetisation point we do plan to have a paid version of the product too. We think that one of the limiting factors of using symbolic execution to date has been in the path explosion problem when analysing large programs. A large part of our reasoning behind building a new symbolic executor from scratch was that we wanted to be able to parallelise it to help overcome this issue. We intend to provide a cloud hosted version of Symbolica that makes use of this so that users can get access to this compute power on a pay per use basis.

So our rough plans at the moment are to charge on a consumption basis to use this service.

[BiteCode_dev]

Thank you.

> The key difference is that we don’t actually invoke the code with concrete values, but rather treat it like a set of constraints that should always be satisfied

How does that work with a dynamic language such as Python?

[Choc13]

The static type information isn't actually too important to us, what our tool cares about is being able to interpret branching conditions in the code in order to turn them into constraints. We currently do this at the LLVM IR level, so as long as we can compile the code down into this form then we can analyse it. With Python a lot of the work we had to do in order to get a prototype working was in being able to handle all of the system calls that the Python interpreter needs to make when booting up. These aren't always straight forward to treat symbolically because they interact with the file system etc, but it's possible to provide mock implementations that don't affect the analysis of the users code.