[nerdtime]

>You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.

Why the heck would I run such a long expose and troll you and be mistaken at the same time.

>How does this Haskell program write to stdout if it doesn't mutate memory?

Let's not be stupid here. Every program on the face of the earth must mutate memory because that's how computers work. Assembly instructions mutate things. We're not even talking about that. We're talking about application level programming where we only deal with primitives that the application programmer is aware about. I am saying that at the application level within the category of Hask nothing is mutated.

In your example tell me what haskell primitive.... What variable or data was mutated within haskell? That is what I'm referring to.

Try to implement IO or ST in another lang using only purely functional primitives. Use your algebra to make it work. You'll find it's impossible. What this means is that imperative primitives must exist for any programming to work.

>Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur.

Obviously I'm operating on a certain layer of abstraction here. In X = 6, X is obviously immutable in haskell. A runtime is obviously executing your haskell program and mutating the console but your haskell code itself is pure. But you know this. It's quite obvious you're the one that's trolling.

[phizy]

>What variable or data was mutated within haskell?

The stdout buffer.

Just because mutation isn't explicit doesn't mean it isn't there. Programming languages are not syntax devoid of meaning: they have semantics. What happens at runtime is part of what a programming language does. (Arguably, that is the most important part of what they do.)

>What this means is that imperative primitives must exist for any programming to work.

That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa. Again, they're just different models. No language can do anything if it isn't implemented in a machine. A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction. You absolutely could implement a pure functional assembly language. The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].

Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.

> Use your algebra to make it work. You'll find it's impossible.

Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/... [3] https://en.wikipedia.org/wiki/Lisp_machine [2] https://en.wikipedia.org/wiki/Turing_completeness

[nendroid]

>The stdout buffer.

The stdout buffer is not part of the haskell language, it is part of the OS. The haskell runtime reads the haskell language and accesses the buffer. Neither the runtime or the buffer is part of the haskell language, get it? That's why haskell is called "pure" Category Hask: https://wiki.haskell.org/Hask#:~:text=Hask%20is%20the%20cate....

>Just because mutation isn't explicit doesn't mean it isn't there.

So? I never said it wasn't there. I'm basically saying as far as the programmer is concerned when operating within the haskell language no haskell language primitive is mutating. stdout buffer is not a haskell primitive... it is an OS primitive.

>That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa.

This is true theoretically, but physically but you can't actually build a functional machine. Lisp isn't actually a functional language and you'll see from the instruction primitives that the lisp machine is more or less a turing machine that mutates memory.

>No language can do anything if it isn't implemented in a machine.

So? Never said this wasn't true.

>A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction.

The machine you build is limited by what you build it with. You have a limited set of atoms. Therefore you can only build a machine with limited amount of state. In order to use the state efficiently the state must be mutable. Mutable state means imperative instructions. You can imitate functional programming with such a machine and you can sort of solve the memory problem with garbage collection. But with what paradigm do you implement the garbage collector? Imperative primitives.

> The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].

No the real reason is also because it's physically impossible. A physical translation of a actual lambda machine cannot be realized. What they can make is register based machine that are more efficient at compiling certain functional languages that's it. All machines we build have some sort of state that changes.

>Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.

Sure I can prove what I said. But you're changing the problem from IO and ST to a computable function which I assume is algebraic. So of course all of algebra can be used to create all algebraic functions. I'll just prove what I said rather than what you changed it to.

Assuming mutation is an axiomatic operation that cannot be built from immutable operations, you will see that no mutation operation exists in algebra indicating that mutation cannot ever exist in any theorem of algebra:

https://www.wikiwand.com/en/Algebraic_operation#:~:text=In%2....

You will see that no algebraic operation involving mutation exists in the above document.

>Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.

No but I can implement volatile with imperative primitives from other languages. All I am saying is you cannot implement ST and IO with functional primitives.