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.