It should be possible to optimize the internal representation of the program's code to collapse consecutive +, -, < and > tokens and make the interpreter execute a single instruction representing all of them instead of a single instruction at a time.

Depends on #9.

As per language specifications, the interpreter should have at least 30K empty memory cells. Since we mem_resize the cell pool when they're not enough this isn't a problem, but we could improve things and provide 32K empty cells right from the start.

Strictly decrementing loops (like [-]) can be safely optmized to something along the lines of *value = 0; we should do that.

Depends on #9.

Since we're using realloc to deal with memory resizes and at the same time using a doubly-linked list we run into problems when realloc can't resize .cells in place, since all the cells' .next and .prev potentially become invalid.

Probable fix: make .next and .prev contain indices into .cells instead of pointers.

We're currently missing error checking everywhere in the application: when creating the vm, the memory store, the loop stack.

Current internal representation has a 1:1 correspondence to the original byte stream that composed the brainfuck source code.
This should be revised in order to support optimizations like the removal of non-executable / empty loops, collapsing of cell value changes and cell pointer moves.

Memory implementation currently allows negative memory addresses (eg. moving left as a first instruction); this is a complex implementation that involves both a doubly-linked list and a memory-cell pool to avoid allocating them one by one.

Disallowing will simplify code and hopefully improve performance, while still behaving withing specification.

VM should be able to read potentially infinite amounts of code, provided the host system still has memory left; it means we have to realloc memory for the token stream.

Any loop beginning immediately after another will never be executed and can be safely skipped (and thus, removed from the internal representation before code execution).

Rationale: given [ LOOP A ][ LOOP B ], we know that Loop A will execute until the current cell's value is zero. Then, when we enter Loop B, it will be skipped because the cell's value continues to be zero.

Depends on #9.

Script sources are currently read from stdin, which conflicts with the source for user input. Probable fix will be to accept the script's filename via command line argument, freeing up stdin for user input.

The VM implementation should check current cell's value when entering a loop, and it currently does not, which means that loops entered with 0-valued cells are still executed.