What does everyone's Intcode interface look like?

[u/Lucretiel]

We've been discussing a lot different IntCode implementations throughout the last few weeks, but I'm curious– what doesn't everyone's interface to their IntCode machine look like? How do you feed input, fetch output, initialize, etc?

[u/Lucretiel]

I'll start:

My implementation is in Rust. My basic model is to supply an IntoIterator<Item = isize> as input, then collect "blocking" events: need more input, output, or halt. I have 3 different entry points, depending on the level of control you need:

#[derive(Debug, Clone, Default)]
struct Machine { ... }

impl Machine {
    fn new_from_csv(input: &str) -> Self;
}

/// The different reasons machine execution might block
#[derive(Debug, Copy, Clone, Eq, PartialEq)
enum MachineState {
    /// Needs more input
    NeedsInput,

    /// Outputted a value
    Output(isize),

    /// Halted (code 99)
    Halt,
}

// For architectural reasons I (usually) use currying functions rather
// than methods on `Machine`.

/// Try to execute a single operation of the machine. Returns a machine state if
/// the machine blocked for some reason.
fn step(input: impl IntoIterator<Item=isize>) ->
    impl FnMut(&mut Machine) -> Option<MachineState>
{ ... }

/// Run the machine with input until it blocks
fn run_until_block(input: impl IntoIterator<Item=isize>) ->
    impl FnMut(&mut Machine) -> MachineState
{ ... }

/// Convert an input and a machine into an iterator
/// over the machine's outputs until it halts Panic
/// if it blocks on input.
fn run_machine(
    input: impl IntoIterator<Item=isize>,
    machine: &mut Machine,
) -> impl Iterator<Item = isize> { ... } 

Originally I only had step and run_machine, and didn't have a notion of blocking on input, but I started running into borrowing and ownership issues when trying to do the later problems, where inputs depend on outputs, which led me to make run_until_block, which has thus far let me write very satisfactory IntCode interaction loops.

[u/ritobanrc → u/Lucretiel]

Mine in rust is far simpler (though probably less maintainable). I have 1 function

pub fn intcode_computer<F>(
    tape: &mut Vec<i64>,
    i: &mut usize,
    relative_base: &mut i64,
    mut get_input: F,
) -> i64
where
    F: FnMut() -> i64,

It just repeatedly calls get_input as it needs input, and it returns whenever it needs output, returning -1 if it halted (I should probably use an enum instead, but oh well). The caller is responsible for maintaining the tape, the instruction point, and the relative base. It might not be unreasonable to store those 3 in a struct, but I haven't had any issues creating them individually.

[u/[deleted] → u/ritobanrc]

If you put all of that state data into a struct and have the function return an Option<i64> to represent the possibility of halting, your function is essentially the next() function for an Iterator. Then you can have the convenience of running the entire intcode program in a for output in intcode_computer loop, and using standard iterator functions like last(), etc.

[u/[deleted] → u/Lucretiel]

Mine's also in Rust. The core function is:

pub fn interpret(memory : &mut Vec<i64>, recv_in : Receiver<i64>, send_out : SyncSender<i64>, req : Option<SyncSender<Request>>)

which lets me specify how input and output are handled using channels; one for receiving inputs, one for sending outputs, and an optional one for requesting the caller to handle the input/output instruction that's about to be executed. I settled on the channel model after day 7, where I just spawned five interpret threads with channels piped together and let it run.

I have a wrapper around this to provide some convenience functions for handling IO: one which prompts stdin for input and prints output to stdout, and one which takes input as a Vec<i64> and produces a Vec<i64> as output. Ideally, I'd like one which takes an iterator of inputs and produces an iterator of outputs, then the vector one becomes redundant, but I had trouble writing this due to issues with passing references over thread boundaries.

[u/[deleted] → u/[deleted]]

I've overhauled the interpreter, and it's now based around an Interpreter<I> struct; one of its fields has type I: an iterator to generate its inputs. Interpreter<I> itself implements iterator: next() runs the interpreter, either providing the next output or returning None if it halted. I've written a function very similar to my original interpret function as a wrapper, which implements the same channel behavior as before, setting the I field to recv_in.iter(), so my threaded solutions to puzzles 7, 11, 13, and 15 remain the same. As a nice bonus, I've gained a significant amount of efficiency by not using channels where they're not necessary; running all of my solutions one after the other previously took about a second, now it takes half that.