6 ms·
>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context. Haskell does inhibit mutabi
by nerdtime 6y ago
>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.
Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program modelling mutation if the program can't actually do mutation or IO.
>Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.
Location meaning outside of haskell. Like your database. I'm saying within haskell you have a variable.
x = 3
You can never mutate that variable in haskell. However you can mutate the state of the console without ever mutating any state within haskell.
print "hello"
The above triggers no mutation in haskell. A runtime outside of the haskell universe analyzes the IO instructions and mutates the console. What I am saying is that the thing that mutates the console has to do mutation. Whoever wrote that thing HAS to write imperative primitives. They are moving the imperative nature of programming INTO a framework. They are not eliminating the problem.
This is the same thing as a database string. UPDATE. You are moving all the imperative errors that have to deal with threading and mutations to the database. But your haskell sql string is still pure.
Again my argument is just saying that this thing that is doing the UPDATE or mutating the console cannot be built using haskell style code or immutable algebraic concepts. Imperative primitives need to exist and someone needs to use those primitives to do the actual mutations.
The OP is basically saying algebra is the future and it can replace everything. I'm saying it CAN'T.
>Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.
And honestly you sound like the guy standing on the iron boat. The person I'm shouting at is you, but you're just dismissing me.
- phizy 6y ago> Your haskell program does not mutate. Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur. You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.
- nerdtime 6y ago>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 6y ago>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/1993/01/imperative.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [3] https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine [2] https://en.wikipedia.org/wiki/Turing_completeness https://en.wikipedia.org/wiki/Turing_completeness