Jonathan Lang wrote: >How does an atomic block differ from one in which all variables are >implicitly hypotheticalized? I'm thinking that a "retry" exit >statement may be redundant; instead, why not just go with the existing >mechanisms for successful vs. failed block termination, with the minor >modification that when an atomic block fails, the state rolls back? > >
State rolling back automatically is the key feature of STM. However, it can only cover pure perl state; any time that you enter a function that performs I/O of any kind, then you are forcing bad things to happen. With Haskell this is sorted out by making the default "pure", and everything else must be in a Monad. However we're not into bondage here so "is pure" is not default. Instead we just die and rollback just before I/O is attempted. In principle, the compiler could automatically attach "pure" traits to all functions and methods that it can prove will never perform I/O and warn about this at compile time. It might be possible for clever classes to circumvent this and carefully call special unsafeIO() methods, and be passed messages about the STM and hope that they do the right thing. I don't know that anyone's explored this area in depth in Perl 6 space. >Also, what can "retry_with" do that testing the atomic block for >failure can't? > I think the answer lies in the "checkpointing" references in that document. I don't know whether that's akin to a SQL savepoint (ie, a point mid-transaction that can be rolled back to, without committing the entire transaction) or more like a continuation that when resumed can see the atomic changes, and when exiting finally applies them (or rolls back). Perhaps someone else will have more of a clue. Sam.
