3 ms·
No, the statement isn't nonsense. If variables always had the same value and "never changed" in Haskell, they wouldn't be variables. They could be hard-coded li
by SiVal 12y ago
No, the statement isn't nonsense. If variables always had the same value and "never changed" in Haskell, they wouldn't be variables. They could be hard-coded literals.
You're just mistaking a claim about variables that change each time a program is run (which means they are initialized to a different value each time, whether mutable or immutable) vs. changing during the execution of a single run, which would require mutability.
The quote was referring to the former, not claiming that mutability is required.
- deleted 12y ago[deleted]
- vq 12y agoNot that quadrangle made that point, but a program written in point-free style could still exhibit dynamic behaviour. Still not very constructive or relevant criticism on the page though.
- tel 12y agoThe statement may not be nonsense, but it's certainly not at a level of detail required to be genuinely true. Variables do always have the same value and never change in Haskell. They represent constant abstracted unknowns. That said, a lambda binder which introduces a variable can be applied repeatedly and therefore each independent time it's applied the body of it, where the abstraction occurs, is now understood to operate with a new value for that variable. That's very different from change, though. The semantics of beta reduction clearly don't allow for change---merely substitution. The statics of it clearly demonstrate that even substitution isn't doing anything new---merely replacing like for like. Even when your Haskell program responds to outside interaction---clearly, this is dynamic information, right?---it's still the same static artifact which is doing it. The variables at this point are all erased. It's merely the semantics of your program under outside intervention.