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. The whole point of
multi-threading is to be able to respond asynchronously to events i.e. the
relative order of events in one thread versus another thread is undefined - if
the order were defined the program would be single-threaded. Take that together
with the ability to perform side-effects e.g. I/O or mutable state, and it is
clear that the results produced by the program will in general depend on the
particular relative order of events between threads, rather than on the
declarative semantics alone.
It is possible to achieve some of the effects of multi-threading using lazy
evaluation of stream processors - this approach does not violate referential
transparency, and is used in the Fudgets GUI (Haggis uses concurrent Haskell).
I ran some Haggis programs in the days before it rotted, and it performed
well. I haven't run Fudgets programs, but got the impression from the
documentation that the stream processors would not always provide as much
responsiveness as could be wished for.
Tim
