nixpulvis / brainfuck

A simple brainfuck interpreter in Rust.
http://nixpulvis.com/brainfuck
23 stars 3 forks source link

Overflow Semantics #16

Closed nixpulvis closed 8 years ago

nixpulvis commented 8 years ago

I keep flipping on this, and exactly how the program should act. We just need to spell it out and stick to it. The questions that need answers are what are the semantics of (over/under)flowing the value of a cell. What are the semantics of (over/under)flowing a pointer. This one might need to be dynamic to the size of the tape. Also begs the question should the tape be fixed? Should there be configurations for this?

nixpulvis commented 8 years ago

The documentation currently says that overflows will result in an Err, when in reality it panics.

nixpulvis commented 8 years ago

Here's a proposal for a better interface for the tape.

trait Tape: Deref {
    type Cell;

    fn set_val(&mut self, val: Self::Cell) -> Result<Self::Cell, Error>;
    fn inc_val(&mut self) -> Result<Self::Cell, Error>;
    fn dec_val(&mut self) -> Result<Self::Cell, Error>;

    fn set_ptr(&mut self, val: usize) -> Result<usize, Error>;
    fn inc_ptr(&mut self) -> Result<usize, Error>;
    fn dec_ptr(&mut self) -> Result<usize, Error>;
}

This unfortunately means dropping the operators +=, -=, >>= and <<= because they don't allow returning result types. The *tape operation will remain, because accessing the tape should still be unconditional.

Storage of a tape in the interpreter will be inside of a Box<Tape> so that the implementation of the tape is abstract. For example the first implementation of a tape might be impl Tape for Vec<u8>.

Implementing Deref for other types might cause issues, so there's a chance we'll drop that notion as well for fn get_val(&self) -> Self::Cell.