Manuel M. T. Chakravarty writes:
> <[EMAIL PROTECTED]> wrote,
>
> > Adrian Hey writes:
> > > On Wed 06 Oct, Johan Nordlander wrote:
> > > > Just to avoid any unfortunate misconceptions: O'Haskell definitely
> > > > preserves the property we commonly refer to as referential transparency,
> > > > and so does Concurrent Haskell, or any other sound monadic extension of
> > > > the language.
> > >
> > > Hmm, I obviously don't understand what 'referential transparency' means.
> > > I must say I'm puzzled by statements like this. If the presence of
> > > mutable variables (and MVars in Concurrent Haskell) preserve referential
> > > transparency, then why _don't_ we have referential transparency in C?
> >
> > I'm not surprised you are puzzled. Concurrent Haskell, as
> > implemented in ghc, does NOT preserve referential
> > transparency, nor could it.
>
> Of course it does! If it wouldn't many of the optimisations
> performed by GHC would be invalid and you would be doomed if
> you compiled a Concurrent Haskell module with -O (actually,
> you would most certainly already be doomed without -O).
>
> Check out the type signatures of the `MVar'-related
> operations and you will find that they are all nicely
> encapsulated in the `IO' monad.
That does not help. Encapsulation within the IO monad forces MVar operations
to be explicitly ordered only within the thread in which they occur; it does not
effect the relative order with respect to MVar operations in other threads.
See the paper "Concurrent Haskell" by Simon Peyton Jones, Andrew Gordon and
Sigbjorn Finne, which states:
"forkIO :: IO () -> IO () forkIO a is an action which takes an action, a, as its
argument and spawns a concurrent process to perform that action. The I/O and
other side effects performed by a are interleaved in an unspecified fashion with
those that follow the forkIO."
The paper goes on to say:
"The situation worsens when concurrency is introduced, since now multiple
concurrent processes are simultaneously mutating a single state. The
purely-functional state-transformer semantics becomes untenable.
Instead, we adopt the standard approach to giving the semantics of a concurrent
language, using an operational semantics."
In summary, Concurrent Haskell only has declarative semantics for an individual
thread (called a process in the paper) - the entire program does *not* have
declarative semantics i.e it is not referentially transparent.
For example, consider a program where one thread prints a value from an MVar,
while another thread modifies it. The output of the program will vary from one
run to another, even though its input (none) is unchanged.
Tim
