My thinking was that completely immutable functions map better to hardware that can't change its own design, but maybe it would be better to allow state sometimes. The problem with state is that it implies sequentialism.

Registers, signals, etc. can change values, but you can't change what they do or how they're used. So you can't really have anything like self-modifying code. But I guess allowing state would make sense sometimes as long as you are mindful of what the state is dependent upon. Making lots of independent little state machines would map well to hardware I think.

"Strict" and "immutable" are rather different things. Which one did you mean? None of them really are related to self-modifying code though.

Oh, I meant immutable. Thanks for pointing that out!

Because hardware is fundamentally strict, when you read a value you read it.

This is not what 'strict' really means. 'Strictness' means that a function must evaluate its argument. In terms of h/w this would mean (I guess) that a 'strict' circuit must read its inputs, which is not usually required.

Is it ? aren't there differential circuits with history that won't activate the subsequent circuitry in case the read value didn't change ?

The order of operations is strict, when you specify you want something you grab it. In contrast Haskells evaluation order does not match the definition order necessarily.