On 2006-02-03 garrett_damore@tadpole.com wrote:
> Curt Sampson wrote:
> > http://research.microsoft.com/~simonpj/papers/stm/index.htm
> In interesting idea -- transactional memory. I didn't read the whole
> paper, but just conceptually I'm not convinced that it really eliminates
> the problem. It provides developers with a different approach that may
> be easier, but it also requires programmers to properly handle
> idempotency. This is great for pure computation, but for stuff that
> interfaces with e.g. devices, networks, etc., idempotency can be a real
> gotcha.

  I think a model based on RCS style branching and merging would help with
this; combined with transactions and a means of rendezvous, it would at
least help make reference assumptions explicit and provide the basic
building blocks for comprehensive dependency.  IMO, integrating
transactions and branching at the system level, including the file system,
would be a major improvement.

  I also think it would be an improvement to use non-blocking tasks as the
foundation of interfaces, leaving threads and interrupts as a variable
means of managing priority.  I think blocking could in that case be
related to errors in terms of effect on program structure and difficulty
of modification.

  The O'Haskell rational describes an interesting model of non-blocking
objects ("reactive objects"):
http://www.cs.chalmers.se/~nordland/ohaskell/rationale.html

Matthew Ogass
darkstar@city-net.com