Re: [tlug] STM (was: Re: work times & accommodation @tokyo)

[Curt Sampson <cjs@example.com>]

On 2008-07-30 15:36 +0900 (Wed), Stephen J. Turnbull wrote:

> Curt Sampson writes:
>  > On 2008-07-30 10:06 +0900 (Wed), Stephen J. Turnbull wrote:
>  > 
>  > > Make it a separate class, with private members for the value and the
>  > > log.
>  > 
>  > I guess that this is the part I'm not clear on.
> 
> I'm not, either.  Clearly what needs to be done is to create an
> AtomicSequence type, which has access to and validates the log(s)
> before it exits.

Err, "yeah." Something like that. :-) Of more concern, as I said, is how
you make this work for every TVar (or equivalant thereof) in the entire
JVM.

> The sketch in "Beautiful Concurrency" is nowhere near as detailed as I
> remembered it....

I thought it was enough for someone experienced with monads in Haskell
to get enough of an idea of what's going on to implement it.

> ...and I was confusing the implementation of 'atomically'
> with that of the 'TVar' itself.

Right. This is about all uses of any TVars, not just one.

> Oh, brain fart, I guess.  I was thinking that you might read or write
> variables in such a way that there's no external effect, but of course
> Haskell doesn't really have variables in that sense.  Anything that
> resembles a C variable will be I/O in Haskell.

Actually, no. You use monads to sequence operations, but if you look
at something like the State monad, there's no I/O (or IO monad)
involved. It's an entirely separate system built in the same way, with
the exception that IO includes a bunch of low-level "magic" (just
pseudo-magic, really) that deals with the idea of "the real world."
(Mostly this is just doing a proper wrapping of the C library functions
that have side-effects.) You can think of the State monad as just
another implementation of an alternate "real world" that needs no
special support, since it's contained entirely within the language.

>  > Well, at least that moves C++ into the "it's theoretically possible"
>  > category. However, it's starting to sound as if "the C++ typechecker can
>  > do anything Haskell's can do" is like "6502 assembler can do anything
>  > that Java can do, because they're both Turing-complete."
> 
> Yes, of course.  But sometimes it's worth doing it.  Eg, in the XEmacs
> case, we have strong reasons to stick with the existing C code base.

Right. That's a reasonable trade-off, and probably the one I would make.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com