General discussions: Brainfuck Interpreter

Matthew Cole 2015-01-15 08:40:08

Everyone,

I'm tackling the BF Interpreter, and I have some questions about the behavior specification of the BF++ language.

What happens if < is used often enough to move the data pointer past the left edge of the memory array? Is it allowed as long as you don't try to access that index in the memory array before the data pointer moves back into the memory array, or is an error raised?
Assuming the [ and ] commands are implemented as a stack, what happens if one attempts to pop from an empty stack? Is it ignored and the code pointer moved right, or is an error raised?
What happens if , or ; is called, but no input exists? Is it simply ignored and the code pointer moved right, or an error raised?
What happens if $ is called, but the stack is empty? Is it ignored and the code pointer moved right, or is an error raised?

TLDR: Are stupid commands ignored (naive failure), does the interpreter give up and return some sort of error (disgraceful failure), or is there some sort of error handling mechanism like exceptions (graceful failure)?

Rodion (admin) 2015-01-15 10:58:27

Matthew, Hi!

BF has many subtle things left unspecified. I'm afraid it is the same with our "BF++" implementation.

I believe that escalating failure when encountering any of such conditions will significantly help in debugging. Though I'm not sure my own implementation always followed this rule. (I hope I'll improve it one day - for now I file an issue as a reminder).

When you solve "Brainfuck Interpreter" problem (its test-cases should be free of such erroneous conditions) then "notes" for it you will be able to see the link to my implementation.

As I look at my code I see that:

No error is raised on making data pointer negative, but you may see that following operations on this data field are incorrect.
Looks like it is ignored, though it is bad.
This is tricky - when you input from keyboard, there is no sense in "end of input" - program will simply wait... When running in batch for ; error is reported, but not for ,.
Error is raised properly.

So you see, the main idea is that such things should not affect "correct" program. Though now I sadly think that built-in interpreter should be improved to be more intelligent...

Well, thanks for pointing this out :)

TestUser 2015-01-19 14:35:20

Few checks were added:

for "<" moving data pointer below 0 position;
for unequal amounts of "[" and "]";
for operation "," when input is exhausted;
for using stack operations when checker does not allow them (does not affect test run feature).

Hope all works properly, though please feel free to report any problems!

P.S. As you may guess Admin and TestUser are two cases of "multiple personality disorder" of a single person :)

Matthew Cole 2015-02-13 04:25:38

So I finally finished my interpreter.

This is my first CodeAbbey problem that uses both the Object Oriented Programming style and extensive exception handling. I'd appreciate commentary on the implementation, especially from more senior Pythonistas. Thanks!

Moff 2015-02-13 08:16:57

I've wrote my BF++ interpreter more simpler, without catching exceptions and other pretty things, just for debugging solutions. Here it is

Moff 2015-02-13 08:19:26

Matthew: you code looks accuracy and complex. But IMHO it's more java styled than pythonic way :)

Rodion (admin) 2015-02-13 15:55:25

> But IMHO it's more java styled than pythonic way :)

You've made me curious - could you explain this bit more since I'm not well acquainted with Python and, eh... pythonic way... :-o

P.S. Added link to my version below your post, though I do not think many people are interested in PHP-version :)

Moff 2015-02-13 17:41:05

It's hard to explain (there is a lot of holywar at forums about kind of pythonic way). Exec at console:

import this

Use the Force, Luke :)

Norbiox 2017-07-12 18:35:35

Hello, I'm trying to write this BF interpreter, but probably I can't see something. Everytime when I'm testing my interpreter it returns 3 numbers, not as many as it's expected. So I've counted those '<' and '>' marks in test data to check if pointer can be bigger than 2 and I see that is impossible. This function helped me to count marks and max data pointer:

def checkPointerMovers():
    data = input()
    [left, right] = [0,0]
    max_pointer = 0
    for mark in data:
        if mark == '<':
            left += 1
        elif mark == '>':
            right += 1
        if right - left > max_pointer:
            max_pointer = right - left
    print(left,right, max_pointer)

Except that I'm missing something what is increasing data pointer too. Could anybody help, please?