3 ms·

>the update of game-state itself does not require mutability at the language level, This is more inline with what I mean. The muteability must happen somewhere

>the update of game-state itself does not require mutability at the language level, This is more inline with what I mean. The muteability must happen somewhere whether it's a framework or a language it is being hidden from you via a black box. It doesn't matter whether or not the language is FP or not, it is the paradigm I am talking about as you can do FP in any language. The way you describe it via the GC, is a leaky abstraction. At the language level the immuteable data strucure must exist forever, but underneath this, what is occuring is mutation behind a black box. If at the language level where all things are immuteable you treat everything as the abstraction says you should and reference past state your program will overflow. Therefore in order to do your technique properly you must know what's going on underneath in order to properly use the functional abstraction in this way as the leak from the blackbox limits you in what can be done in the FP paradigm.

dwohnitmok 7y ago
The situation is not any different for an imperative GC language. They don't offer any way of destroying an object, so the abstraction says an object once instantiated should stay around forever. And e.g. the JVM has a setting for this (see the Epsilon GC). Of course you eventually run out of memory and blow up, even in imperative code. Indeed, even the choice to say have an operation like x++ not allocate additional memory is implementation defined. In Python (and in Java if this is an Integer), sometimes this is an object that is not mutated in place, but rather a new copy is created. This is very implementation dependent. For most varieties of the JVM this behavior kicks in only once your integer is greater than 127. Below it they all share a pool of the same integers. In those cases x++ is only a constant space operation because of GC, not because of imperative semantics. It's all black boxes everywhere. The distinction here is between GC and non-GC not functional and imperative. In a deeper sense our conversation is a sort of category error. Immutability and mutability are both examples of language-level semantics that are implemented in many different ways. Mutability can be implemented by an immutable underlying system (the prime example of this is Copy-on-Write file systems) and immutability can be implemented by a mutable underlying system. The implementation layer has its own set of semantics distinct from the semantics of the language itself. The whole spark that drove all this, is that at the moment of update immutable structural sharing is generally not implemented with mutability, which while never explicitly stated, was what I guessed galaxyLogic was getting at (their questions all seemed to stem from this assumption). Mutability may come into play later, but at the time of update, there is no mutability. I emphasize this, because this is not how React works. With React you're correct that each update to the virtual DOM results in ultimately a mutable update to the real DOM. This is not how structural sharing with immutable data structures works. There is no such one-to-one correspondence. It is generally not the case that, e.g. there is a single mutable array backing a family of immutable data structures with complex book-keeping to maintain a facade of immutability (although of course if you wanted to you could implement it this way). The virtual DOM by itself is often implemented with structural sharing but that's a different story.
- crimsonalucard 7y ago
  I am 100% aware of what you're talking about and the differences between what you're talking about and react. You are largely correct on the GC and non-GC distinction. However, even accounting for this a cheat must still occur somewhere else in the pipeline. That immutable data structure you're talking about must be fed to IO which updates the screen. This is equivalent to updating the virtual DOM. This is where the one to one correspondence forms with FRP. The "cheat" so to speak... whether a framework or an outside runtime implements it no computer system can truly implement FP and they all must cheat. You could argue that we're not talking about things at that level of abstraction but I would argue that for gaming and systems level programming, this level of abstraction is critical to the topic at hand.

dwohnitmok 7y ago

The situation is not any different for an imperative GC language. They don't offer any way of destroying an object, so the abstraction says an object once instantiated should stay around forever. And e.g. the JVM has a setting for this (see the Epsilon GC). Of course you eventually run out of memory and blow up, even in imperative code. Indeed, even the choice to say have an operation like x++ not allocate additional memory is implementation defined. In Python (and in Java if this is an Integer), sometimes this is an object that is not mutated in place, but rather a new copy is created. This is very implementation dependent. For most varieties of the JVM this behavior kicks in only once your integer is greater than 127. Below it they all share a pool of the same integers. In those cases x++ is only a constant space operation because of GC, not because of imperative semantics. It's all black boxes everywhere. The distinction here is between GC and non-GC not functional and imperative. In a deeper sense our conversation is a sort of category error. Immutability and mutability are both examples of language-level semantics that are implemented in many different ways. Mutability can be implemented by an immutable underlying system (the prime example of this is Copy-on-Write file systems) and immutability can be implemented by a mutable underlying system. The implementation layer has its own set of semantics distinct from the semantics of the language itself. The whole spark that drove all this, is that at the moment of update immutable structural sharing is generally not implemented with mutability, which while never explicitly stated, was what I guessed galaxyLogic was getting at (their questions all seemed to stem from this assumption). Mutability may come into play later, but at the time of update, there is no mutability. I emphasize this, because this is not how React works. With React you're correct that each update to the virtual DOM results in ultimately a mutable update to the real DOM. This is not how structural sharing with immutable data structures works. There is no such one-to-one correspondence. It is generally not the case that, e.g. there is a single mutable array backing a family of immutable data structures with complex book-keeping to maintain a facade of immutability (although of course if you wanted to you could implement it this way). The virtual DOM by itself is often implemented with structural sharing but that's a different story.

crimsonalucard 7y ago
I am 100% aware of what you're talking about and the differences between what you're talking about and react. You are largely correct on the GC and non-GC distinction. However, even accounting for this a cheat must still occur somewhere else in the pipeline. That immutable data structure you're talking about must be fed to IO which updates the screen. This is equivalent to updating the virtual DOM. This is where the one to one correspondence forms with FRP. The "cheat" so to speak... whether a framework or an outside runtime implements it no computer system can truly implement FP and they all must cheat. You could argue that we're not talking about things at that level of abstraction but I would argue that for gaming and systems level programming, this level of abstraction is critical to the topic at hand.