I know machine learning can make some predictions. With enough input data and example output data a machine can accept an image as input and determine that the image is likely a "flower" (output).

Could the same method apply to an interpretive programming language? Let's say Python for example. The inputs on every "line" of python would be existing memory and the new "line" of syntax. So if x = 2 (some data in ram as say CPython would set it instead of the actual syntax). Our new line of syntax is x + 2. The output is 4 (perhaps the updated ram state could also be considered an output). With enough sample input and output could a machine learning algorithm effectively "invent" it's own python interpreter? Perhaps our invented interpreter would determine there is a 98% chance that 2 + 2 results in 4.

A few people are asking why would anyone would want to do this. Curiosity mostly and certainly reading too much Godel, Escher, Bach. I think it's interesting because:

  • Perhaps it would find novel optimizations. Computers already find new strategies in chess. Why not interpreters or compilers?
  • The idea of a programming language interpreting syntax probabilistically, that doesn't even have to follow strict rules, is interesting. Can we go from 2 + 2 = 4 to 2 plus 2 equal four to Please add two and two.
  • Making a really horrible python interpreter would be funny.
  • $\begingroup$ I don't think machine learning is quite at this stage right now. $\endgroup$ Mar 1, 2017 at 0:53
  • $\begingroup$ Why would you want to? The point of machine learning is to figure out approximately what's going on when you can't write explicit rules to describe the situation. With a programming language, you already have the explicit rules, and you want to use them to figure out exactly what's going on. $\endgroup$ Mar 1, 2017 at 23:19

2 Answers 2


I doubt it. That requires learning a pretty complex function, which seems beyond the reach of current machine learning techniques.

But there's probably no reason to use machine learning for this, as we already know how to program an interpreter, and that will be more effective than using machine learning.


I haven't seen anybody ever trying this.

However, Karparthy tried if Character-RNNs can create new code in The Unreasonable Effectiveness of Recurrent Neural Networks:

 * Increment the size file of the new incorrect UI_FILTER group information
 * of the size generatively.
static int indicate_policy(void)
  int error;
  if (fd == MARN_EPT) {
     * The kernel blank will coeld it to userspace.
    if (ss->segment < mem_total)
      ret = 1;
    goto bail;
  segaddr = in_SB(in.addr);
  selector = seg / 16;
  setup_works = true;
  for (i = 0; i < blocks; i++) {
    seq = buf[i++];
    bpf = bd->bd.next + i * search;
    if (fd) {
      current = blocked;
  rw->name = "Getjbbregs";
  regs->new = blocks[(BPF_STATS << info->historidac)] | PFMR_CLOBATHINC_SECONDS << 12;
  return segtable;

Now, without executing it, what does the code do?

Did you have problems with that? Well, in that case I hope it helped to illustrate how difficult the task is you're asking. And I didn't even start with ioccc (e.g. this gem and more)

Having said that, I guess it could work for simple instances pretty well. Just finding print("[whatever]") could work. But I don't thing it would understand loops. Yet alone variable assignments. But I didn't try.

  • $\begingroup$ This is the closest I've seen to it so far. I'll mark as the answer if I don't get anything better. It certainly sounds hard (but maybe not impossible some day) to do. I bet I could make the worst Python interpreter ever. This is somewhat related too. Could machine learning reverse engineer an atari or a cpu for instance and make it's own x86 implementation just by using the input and output of the cpu? $\endgroup$
    – Bufke
    Mar 2, 2017 at 1:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.