Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all, <code>Vector</code> is an immutable data structure. Any time you "modify" the <code>Vector</code>, you're creating a whole new copy of it, meaning each modification takes O(n) time (where n is the length of the vector).</p> <p>Second of all, values in Haskell are immutable. Any time you modify a <code>TVar</code>, you are replacing the old value with a new value.</p> <p>I think what you want is a purely functional data structure supporting efficient update. Two examples:</p> <ul> <li><p><a href="http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Map.html" rel="nofollow">Data.Map</a>: Key-value dictionary. This is like <code>std::map</code> in C++.</p></li> <li><p><a href="http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html" rel="nofollow">Data.Sequence</a>: Like a mutable array, but better.</p></li> </ul> <p>Any time you "modify" one of these data structures, you're actually constructing a new value that internally points to parts of the old value.</p> <p>A couple guidelines:</p> <ul> <li><p>If you're only modifying a single value, <a href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data-IORef.html#v%3aatomicModifyIORef" rel="nofollow"><code>atomicModifyIORef</code></a> may be sufficient. If more sophisticated synchronization is needed besides atomic update, <code>STM</code> would be a better choice.</p></li> <li><p>Watch out for laziness when working with mutable variables. Any time you modify the shared state, be sure to force it. This can be done using <a href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html#v%3aseq" rel="nofollow"><code>seq</code></a>. A more convenient way is to use <a href="http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns" rel="nofollow">bang patterns</a>. Example:</p> <pre><code>!x &lt;- atomically $ do x &lt;- readTVar shared_state writeTVar shared_state (changeSomething x) return x </code></pre> <p>This forces <code>x</code> to be evaluated after the transaction completes. If a variable (<code>IORef</code>, <code>STRef</code>, <code>TVar</code>, etc) is modified a bunch of times but never forced, thunks will pile up in memory. Evaluating the resulting thunk may even produce a stack overflow.</p></li> </ul> <p>If your program needs to be massively parallel (that is, have multiple cores/CPUs access the variable simultaneously), updating a single value like this may be less efficient, as computations may be duplicated among processors. However, for a small number of cores, duplication is pretty rare.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload