> Thanks for the informative reply. A CPU might not be functional as in Haskell with recursion and types, but it is a weaker kind of functional in the sense that given the same inputs it will return the same outputs - it has no state, and even memory access is just a function to set or read from an address and those functions never fail, never throw null pointer exceptions, etc. Do you disagree that a circuit is more an example of data-flow paradigm than an example of the state-machine paradigm?

This is all kinds of wrong. CPUs have tons of state. Registers, program counters, TLB, CPU mode, cache, etc. You're just abstracting all that state away as "input," Using this criteria, you can say that a C program with a global buffer is stateless because the global buffer is just an input for the functions.

You're incorrect on your mental model of functional pureness anyway. Functional languages have state, it is just that the state is immutable.

> For a CPU to take the next step and decide what work to do at each clock cycle it needs only its inputs - it need not inspect the previous work it did in order to decide what to do next - it simply reads the next opcode the user wants to execute, and does it. That means it is referentially transparent. Which means it's tons more functional than C.

Incorrect. A modern CPU will often look at different stages in its pipeline in order for other stages to progress. This is one of the reasons you have instruction re-ordering. You can also hit a point where you have to flush the pipeline and start your operation over because you had a branch prediction miss.

In other words, CPUs are highly stateful. You are simply incorrect.