3 ms·

Why do you need a mutable variable? I thought we were discussing functional programming, in which case they should be rarely needed :)

seanmcdirmid 9y ago
If you want to keep track of world-current, then you need a variable that changes from world-0 to world-1 somewhere. Conceptual mutability (change over time) doesn't go away because you are using immutable data structures.
- willtim 9y ago
  In functional programming one should model change over time as a stream of immutable values, there is no "conceptual mutability" and no need for mutable variables.
  - seanmcdirmid 9y ago
    "Things that change over time" = mutable. It's in the dictionary even.
    - willtim 9y ago
      Mathematics has successfully modelled change over time for hundreds of years without mutable memory cells in a computer. Please don't build software that mutates my data. I want history/provenance and reproducibility. I don't mind the odd bit of optimisation, but your use of the phrase "conceptual mutability" would have me worried if I was a customer of yours :)
      - seanmcdirmid 9y ago
        I can give you all that with imperative mutation: https://www.microsoft.com/en-us/research/publication/programming-with-managed-time/ https://www.microsoft.com/en-us/research/publication/program... Of course, I'm a researcher who deals with this field daily, I'm not going to be your ideologue functional programmer who meets your ideological criteria for twisted language with a poor understanding of the wider field.
        willtim 9y ago
        Less of the insults please, I've spent most of my career trying to escape the 'wider field'. The way we choose to model the world is clearly very different.
- bonesss 9y ago
  > If you want to keep track of world-current, then you need a variable that changes from world-0 to world-1 somewhere. Putting on my FP hat: if you need the state of the current world then somewhere you need a side-effect free function that can report that state. If you're managing that state over time then you'll need other functions to handle that stream of immutable data. Conceptual mutability very often isn't a change of data, it's a change in usage/reporting context. And since we're in FP land we could compose those input and handling functions together and splay them across infinite vectors in both directions creating infinite functional chains of potential data interactions that are only calculated on demand based on incoming data. We can be highly confident that those calculations will scale from 1 to 1 million CPUs/machines. We can be highly confident about state-based testing of future states (a la Y2K bug). We can formally verify system behaviour and the underlying data flow. We can also safely and logically match those flows to new and interesting transformations through exhaustive pattern matching with guarantees that we are not impacting the current system behaviour... Granted: there are likely mutable variables somewhere in that turtle-stack, but the overall systems relationship to state will not be impugned by them as long as they are appropriately contained.
imtringued 9y ago
Because that's how you do inter thread communication in haskell. https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Concurrent-MVar.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... >An MVar t is mutable location that is either empty or contains a value of type t. >They can be used in multiple different ways: >1. As synchronized mutable variables,
- willtim 9y ago
  I did say they were rarely needed, if one does need interthread communication then yes an MVar or two will probably be used under the bonnet somewhere. Threads can however be used without MVars. Haskell offers many concurrency and parallel programming primitives. Compare with C++ where every smartpointer holds mutable state (even if it points to a immutable value) and triggers a memory barrier whenever it is accessed.

seanmcdirmid 9y ago

If you want to keep track of world-current, then you need a variable that changes from world-0 to world-1 somewhere. Conceptual mutability (change over time) doesn't go away because you are using immutable data structures.

willtim 9y ago
In functional programming one should model change over time as a stream of immutable values, there is no "conceptual mutability" and no need for mutable variables.
- seanmcdirmid 9y ago
  "Things that change over time" = mutable. It's in the dictionary even.
  - willtim 9y ago
    Mathematics has successfully modelled change over time for hundreds of years without mutable memory cells in a computer. Please don't build software that mutates my data. I want history/provenance and reproducibility. I don't mind the odd bit of optimisation, but your use of the phrase "conceptual mutability" would have me worried if I was a customer of yours :)
    - seanmcdirmid 9y ago
      I can give you all that with imperative mutation: https://www.microsoft.com/en-us/research/publication/programming-with-managed-time/ https://www.microsoft.com/en-us/research/publication/program... Of course, I'm a researcher who deals with this field daily, I'm not going to be your ideologue functional programmer who meets your ideological criteria for twisted language with a poor understanding of the wider field.
      - willtim 9y ago
        Less of the insults please, I've spent most of my career trying to escape the 'wider field'. The way we choose to model the world is clearly very different.
bonesss 9y ago
> If you want to keep track of world-current, then you need a variable that changes from world-0 to world-1 somewhere. Putting on my FP hat: if you need the state of the current world then somewhere you need a side-effect free function that can report that state. If you're managing that state over time then you'll need other functions to handle that stream of immutable data. Conceptual mutability very often isn't a change of data, it's a change in usage/reporting context. And since we're in FP land we could compose those input and handling functions together and splay them across infinite vectors in both directions creating infinite functional chains of potential data interactions that are only calculated on demand based on incoming data. We can be highly confident that those calculations will scale from 1 to 1 million CPUs/machines. We can be highly confident about state-based testing of future states (a la Y2K bug). We can formally verify system behaviour and the underlying data flow. We can also safely and logically match those flows to new and interesting transformations through exhaustive pattern matching with guarantees that we are not impacting the current system behaviour... Granted: there are likely mutable variables somewhere in that turtle-stack, but the overall systems relationship to state will not be impugned by them as long as they are appropriately contained.

imtringued 9y ago

Because that's how you do inter thread communication in haskell. https://hackage.haskell.org/package/base-4.10.0.0/docs/Control-Concurrent-MVar.html https://hackage.haskell.org/package/base-4.10.0.0/docs/Contr... >An MVar t is mutable location that is either empty or contains a value of type t. >They can be used in multiple different ways: >1. As synchronized mutable variables,

willtim 9y ago
I did say they were rarely needed, if one does need interthread communication then yes an MVar or two will probably be used under the bonnet somewhere. Threads can however be used without MVars. Haskell offers many concurrency and parallel programming primitives. Compare with C++ where every smartpointer holds mutable state (even if it points to a immutable value) and triggers a memory barrier whenever it is accessed.