Brainfuck Language

The BadWord police deleted this page. Unfortunately for them, it's about a ProgrammingLanguage and so OnTopic.

Brainfuck is an EsotericProgrammingLanguage. As a language, has some very good points:

And one or two bad ones: Here is a simple brainfuck program:


It will work like Unix cat(1), echoing back all input characters until it reaches EOF.

I can't see why the example is not just ,[.,] neither why it has the [-] -- EduardoMadrid

Clearing the cell each time makes the program work on implementations that leave the current cell unchanged on reading EOF as well as those that set the cell to 0 on EOF, thus increasing the portability. -- DanielCristofani?

Languages inspired by Brainfuck


[ (opening square bracket)
while(mem[ptr]) {
] (closing square bracket)
< (less)
> (greater)
+ (plus)
- (minus)
. (period)
, (comma)

When you make your own language, it is always a good test of usability to try and make a brainfuck interpreter in it. This shouldn't take more than a few hours under most circumstances.

...although there are a few little issues that trip implementors up with astonishing frequency; it would be wise to consult this document, and the two that it links to near the top, first: (Don't worry, they're brief.)

Something from that epistle; every character not part of the language is insignificant whitespace. That's nice for LiterateProgramming (if it wasn't for the reserving of . and - that is!)

How would you implement the following 2 (perhaps this might give me a bit more insight on how to do very simple code-structures with a Turing Machine, given these, any program could probably be built).

 if (x > 0)
  x = 1
  x = 2

(Answer: I'd do [>+<[-]]++>[<->-]< ; this assumes mem[1] is zero and uses it as a temp, and also that mem[0] is not negative, which is the best policy in my view.)

([[-]-<]>++ looks better to me.)

(Some problems with that. One, if x>0 it tries to read mem[-1], which should ideally be a fatal runtime error and is likely to be one in practice. Two, if x==0 it stores 2 in mem[1], not in mem[0]. Three, when it's finished we have lost track of the pointer, which is likely to be problematic in the context of a larger program. Though if we left enough structure around, we could re-establish the pointer's location - e.g.: >+<[[-]->-]>[->]<<++ which assumes that mem[1] and mem[2] are both zero.)

(with a Turing machine this would be something like:

 6 0 2 R 7
 6 1 1 R 7
 6 2 1 R 7
 6 3 1 R 7

Notice that a Turing machine has nothing in common with brainfuck except the memory model and the fact of being TuringComplete.

Not even the memory model is the same. A TuringMachine tape's squares may only contain one of a fixed finite alphabet of symbols, while a Brainfuck tape's squares store arbitrarily large (implementation details notwithstanding) natural numbers. Really, the Brainfuck tape is more like an inexhaustible supply of registers.

Not exactly. Unlimited-range cells are a feature of Frans Faase's dialect of brainfuck, and of his dialect only. If we were going to talk about an ideal brainfuck language independent of any implementations, we would need to base it on Urban M�ller's original readme file, and based on that we would say: a brainfuck tape's squares store bytes (implementation details notwithstanding).

Sum ar: zero to infinity, negative infinity to positive infinity, or 8 bits 0 to 255, or wrapped around or not wrapped around. Another thing would be whether there is more memery left of the starting place.

There isn't more memory left of the starting place in the original implementations, or in most later implementations, there's nothing in the documentation to suggest there might be, and no careful programmer will move the pointer there deliberately. So it's a particularly useless "feature" to add to an implementation. )


 z = &x

(Not clear on that. If you mean something like "find the value of the pointer", there's no way to do that - if your program needs that information, it'll have to keep track of where it moves the pointer to. Also note that the array elements are likely to be bytes, so the address may not fit in one. I think the best move is probably to avoid using absolute addressing schemes where possible.

If you mean something else, please restate.) (Ditto re: Turing machines.)

Also, where is the program stored? Are program and data completely separated?

(Answer: Yes. At least in theory; in some implementations you can violate this.)(Ditto re: Turing.)

See also TuringTarpit, FunctionalTarpit?

I've seen #s, :s, \s, etc. in bf code before. What do they do?

              #>>>-<<<[[>+>+<<-]>[>]+[<]>-[[>]<+[<]>-]<<]>>-[>]#>>>+++++[>+++<-] (Code taken from a quine)

I don't think it does anything. If it was taken from a quine, it was just because the program outputs that, they decided to also add that to the program. In ABF, the # switch with temporary register but I don't think that is standard or anything else does that.

Various people have made implementation-specific extensions to brainfuck, which suggests to me that they didn't get the point. The # command has a certain degree of legitimacy, though, for two reasons: One, it's used for debugging, rather than as an integral part of programs. (Its action is to print the values of the first ten cells of the array, in decimal, and a ^ mark on the next line to indicate the pointer's location; and it doesn't even do that unless you set a "debug" command-line option in the interpreter.)

The second reason is that it was made by Urban M�ller, who invented the brainfuck language.

Since it's clearly undesirable to have a proliferation of special commands, any brainfuck implementor who wants to include any kind of "print internal state, for debugging" function should use # as the command for it. Likewise it'd be a good choice for marking breakpoints, for implementations that feature them.

There's a stupider kid on the block: WhitespaceLanguage


EditText of this page (last edited June 1, 2014) or FindPage with title or text search