<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Passing Curiosity: Posts tagged Haskell</title>
    <link href="https://passingcuriosity.com/tags/haskell/haskell.xml" rel="self" />
    <link href="https://passingcuriosity.com" />
    <id>https://passingcuriosity.com/tags/haskell/haskell.xml</id>
    <author>
        <name>Thomas Sutton</name>
        
        <email>me@thomas-sutton.id.au</email>
        
    </author>
    <updated>2006-05-27T00:00:00Z</updated>
    <entry>
    <title>Transactional memory with data invariants</title>
    <link href="https://passingcuriosity.com/2006/transactional-memory-with-data-invariants/" />
    <id>https://passingcuriosity.com/2006/transactional-memory-with-data-invariants/</id>
    <published>2006-05-27T00:00:00Z</published>
    <updated>2006-05-27T00:00:00Z</updated>
    <summary type="html"><![CDATA[<p><em>Transactional memory with data invariants</em> by Tim Harris and Simon Peyton
Jones. To appear in TRANSACT ’06 (<a href="http://research.microsoft.com/~tharris/papers/2006-transact.pdf">PDF</a>).</p>
<p>I <a href="/2006/transactional-memory-with-data-invariants-draft/">comment previously</a>
on a draft version of this paper. In this ‘final’ version the authors have
removed the wrapper function which converted predicates (<code>:: STM a -&gt; STM Bool</code>) into actions that raise exceptions when the invariant doesn’t hold (<code>:: STM a -&gt; STM ()</code>) leaving the interface a little more consistent.</p>
<p>They have extended the STM monad to use phantom types to restrict the
operations an STM action can perform (<code>ReadOnly</code> or <code>Full</code>) to help restrict
the side effects of invariants. Another addition is support for invariants
over pairs of states: the state before the transaction began, and the state
about to be committed. This is accomplished with a new primitive: <code>old :: STM a -&gt; STM a</code> which executes an STM action in the state as it was when the
current transaction began. Finally, there is some new discussion of drawing on
the work in databases where a distinction is made between <em>assertions</em>, which
detect error conditions, and <em>triggers</em>, which are part of the programmes
logic.</p>
<p>A good paper made even better!</p>]]></summary>
</entry>

</feed>
