On 8 January 2011 11:45, Glenn Maynard <glenn@zewt.org> wrote: > On Sat, Jan 8, 2011 at 6:10 AM, Keean Schupke <keean@fry-it.com> wrote: > > I am suggesting that as the semantics are the same, People can think of > this > > like serialised access, but implementers can use STMs to make their > browser > > faster than the competition (if they want). To the user it will look the > > same. > > Not according to [1]. By the description there, STM requires > re-executing the callback if two callbacks simultaneously modify the > same data and cause a conflict. This is very different to the user, > who has to deal with the possibility of the callback being called > multiple times. Any side-effects of the function would occur multiple > times. This would lead to many subtle bugs, because the retry case > would be exceedingly rare, causing very poorly-tested code paths in > user code. It's also much more complex to spec, and for users to > understand. > > Jonas's approach behaves like any other callback, being called just once. > > [1] > http://book.realworldhaskell.org/read/software-transactional-memory.html > > > -- > Glenn Maynard > Yes, you are right, side effects in JavaScript are a problem. It makes no difference in Haskell, because side effects are tightly controlled. That seems to make serialising them the simplest and easiest to use option. It's not scalable of course - but that seems to be a low priority here. Cheers, Keean.Received on Saturday, 8 January 2011 12:14:54 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT