4 ms·

> As Wikipedia puts it, "An entire processor can be created using NAND gates alone". That's a functional program, whether I'm able to convince you of it or not.

by jawnv6 11y ago

> As Wikipedia puts it, "An entire processor can be created using NAND gates alone". That's a functional program, whether I'm able to convince you of it or not. We're going to explain why you're wrong down below, but a quick note on the logic you're trying to use upon that faulty premise: Just because some processor could potentially be made in a functional manner does not imply that commercial CPUs are done that way. Do you remember why we're talking? > As a final point, consider that your precious C programs and the C compiler can only run because of the CPU, which was not written in C nor in any Von Neumann language - oh no, they were written functionally, with only logic gates, in a dataflow-oriented way You weren't talking hypothetical. You were talking about CPU's that people actually use and their relative stability compared to the terrible software that runs on them. It's really obvious to me that this statement, the entire reason I'm here at all talking to you, was not talking about an abstract Platonic CPU. That you're not admitting it was incorrect and retreating to this ridiculous absurdity is boggling. But you've managed to be wrong yet again, so let's not dwell on the past and just dive into that. > If real-world CPU designers prefer to use state in their processor design that's up to them - but the nature and essence of a CPU obviates state, as a bunch of NAND gates suffices for one as Wikipedia puts it. NAND gates can be combined in such a way as to retain state. The way this reads, I think you're assuming that since a single NAND gate cannot retain state it must follow that any combination of them cannot retain state? Look up "D Flip Flop". Made out of NAND alone, retains state. Given how often you talk about functional things, I'm really really surprised you didn't think about the possibility of feeding an output back into an input. The thing you're missing is what combinations are lurking under that description. I don't think you did the slightest bit of imagining or research on those combinations before declaring all circuitry functional. > Clearly I'm missing something, but I'm not sure I know what. Luckily we've found it! You thought all circuits were limited to Combinatorial logic. You were unaware of Sequential logic. I hope you will reconsider the <i>nature</i> and <i>essence</i> of CPU's in light of this new information.

innguest 11y ago
Unfortunately that's not it - I'm aware of sequential logic and its dependency on past signals - just like the `foldp` function in functional-reactive programming allows one to depend on past signals. If you think that's stateful, then foldp is a state-manipulating function and Haskell is finally impure: https://hackage.haskell.org/package/helm-0.4/docs/FRP-Helm-Signal.html https://hackage.haskell.org/package/helm-0.4/docs/FRP-Helm-S... You still haven't explained to me how come CPUs are so amenable to verification while C programs aren't. Another example, explicitly mentioning Sequential Logic: http://www.cs.cmu.edu/~emc/papers/Papers%20In%20Refereed%20Journals/Automatic%20Verification%20of%20Sequential%20Circuits%20Using%20Temporal%20Logic.pdf http://www.cs.cmu.edu/~emc/papers/Papers%20In%20Refereed%20J... Finite State Machines are amenable to verification. I think (not sure) that must be the difference I'm trying to convey.
- jawnv6 11y ago
  I didn't make a statement about haskell and I'm not interested in parsing definitions that you've shown gleeful disregard for as recently as two posts ago. The 2003 paper isn't using "functional" in your pet manner and I'm not interested in educating such a hostile student. You're clearly reaching for material you don't understand in hopes that I'll be overwhelmed and it's not a good look. If you'd like to pull one of the three (3) usages of "functional" from the 2003 paper and explain how you thought it relevant to your argument I'd be enlightened. If you're just going to come back with a new raft of papers you don't understand from 30 years ago, please save us both the time and spare me. I'm not interested in reading the results of your uneducated googling and teaching you what you found. CPU's are "amenable" to verification in the same way C programs are. Throw enough human bodies, enough time, enough blood, enough sweat, and enough tears, at the creation of a software object and it will be "verified" to be correct. There's nothing inherent in C programs that precludes them from being put through this stringent process. There's a lot of costing reasons why people don't spend that time and effort on a field-patchable software object that they do on gates costing millions of dollars to permanently etch into silicon, but I never said anything approaching "CPUs are so amenable to verification while C programs aren't" because I don't believe your argument to be true. In fact, I'd argue that something like the MRC proves that C-like stateful procedural languages can be put through the same process and result in something just as durable as a CPU, if we're somehow admitting you've been talking about commercial CPU's instead of the goofy abstraction you claimed upthread. Are you planning on addressing how architecturally defined registers aren't stateful? That's a concrete example that posters other than myself also zeroed in on. The only argument given so far was pinned on the NAND equivalence being stateless. It's disappointing you didn't deign to address that in between your wild accusations and gleeful misrepresentations about what I've been saying.

by jawnv6 11y ago

innguest 11y ago

Unfortunately that's not it - I'm aware of sequential logic and its dependency on past signals - just like the `foldp` function in functional-reactive programming allows one to depend on past signals. If you think that's stateful, then foldp is a state-manipulating function and Haskell is finally impure: https://hackage.haskell.org/package/helm-0.4/docs/FRP-Helm-Signal.html https://hackage.haskell.org/package/helm-0.4/docs/FRP-Helm-S... You still haven't explained to me how come CPUs are so amenable to verification while C programs aren't. Another example, explicitly mentioning Sequential Logic: http://www.cs.cmu.edu/~emc/papers/Papers%20In%20Refereed%20Journals/Automatic%20Verification%20of%20Sequential%20Circuits%20Using%20Temporal%20Logic.pdf http://www.cs.cmu.edu/~emc/papers/Papers%20In%20Refereed%20J... Finite State Machines are amenable to verification. I think (not sure) that must be the difference I'm trying to convey.

jawnv6 11y ago
I didn't make a statement about haskell and I'm not interested in parsing definitions that you've shown gleeful disregard for as recently as two posts ago. The 2003 paper isn't using "functional" in your pet manner and I'm not interested in educating such a hostile student. You're clearly reaching for material you don't understand in hopes that I'll be overwhelmed and it's not a good look. If you'd like to pull one of the three (3) usages of "functional" from the 2003 paper and explain how you thought it relevant to your argument I'd be enlightened. If you're just going to come back with a new raft of papers you don't understand from 30 years ago, please save us both the time and spare me. I'm not interested in reading the results of your uneducated googling and teaching you what you found. CPU's are "amenable" to verification in the same way C programs are. Throw enough human bodies, enough time, enough blood, enough sweat, and enough tears, at the creation of a software object and it will be "verified" to be correct. There's nothing inherent in C programs that precludes them from being put through this stringent process. There's a lot of costing reasons why people don't spend that time and effort on a field-patchable software object that they do on gates costing millions of dollars to permanently etch into silicon, but I never said anything approaching "CPUs are so amenable to verification while C programs aren't" because I don't believe your argument to be true. In fact, I'd argue that something like the MRC proves that C-like stateful procedural languages can be put through the same process and result in something just as durable as a CPU, if we're somehow admitting you've been talking about commercial CPU's instead of the goofy abstraction you claimed upthread. Are you planning on addressing how architecturally defined registers aren't stateful? That's a concrete example that posters other than myself also zeroed in on. The only argument given so far was pinned on the NAND equivalence being stateless. It's disappointing you didn't deign to address that in between your wild accusations and gleeful misrepresentations about what I've been saying.