world as value

Fergus Henderson fjh@cs.mu.OZ.AU
Fri, 23 Jul 1999 07:27:35 +1000


On 22-Jul-1999, Adrian Hey <ahey@iee.org> wrote:
> On Thu 22 Jul, P.R. Serrarens wrote:
> > Hmmm. I though we liked a functional approach?
> 
> Up to a point, I certainly like the purely functional approach to internal
> computation and wouldn't want to give it up without good reason. But I am
> begining to have doubts about it as far as issues like IO and program
> behaviour are concerned. Determinism is a nice property, but it also comes
> at a price in terms of constraints on program behaviour.

I think we all agree that nondeterminism is essential, in the sense that
there are some programs which need to have nondeterministic behaviour.

But having nondeterministic behaviour is not the same as having a
nondeterministic denotational (declarative) semantics.
Being purely functional means having a deterministic denotational
semantics, but you can have that and still get nondeterministic
behaviour (i.e. nondeterministic operational semantics).

> > But remember we are working on functional languages: if the result of an
> > action is not represented in the result of the program, then this action
> > should not have happened, otherwise we loose referential transparency.
> 
> Do we really have referential transparency with world as value? I don't
> think so, I think it's been lost anyway.

Yes, we really have referential transparency with world as value.
That is demonstated by my earlier lengthy posts explaining how you can model
"world as value" programs as functions from sequences of input events
to sequences of output events.

> This is is really where we disagree I think. The functional perspective is
> that the purpose of a program (the hidden imperative) is to compute a new
> world value, (and physical IO occurs as a side effect of this). My
> perspective is that generating output is the real purpose of a program, and
> computation is a means to that end. So the hidden imperative is to perform
> _all_ actions present, even if they have no visible effect on the final
> 'world value' (because there is no such thing, in my opinion). 

You're talking about the physical IO and the world value as if they were
different things, but they're not.  The program really does compute a new
world value.  Rather than being stored in a register or memory location,
the world value is stored in the physical world.  In fact the world value
_is_ the physical world.  The implementation does the standard
update-in-place optimization on this value, so that rather than having
to create a new universe to compute a new world value, it can simply
update the value of the existing physical world.

Of course the physical world can be a little bit difficult to reason
about, so it's handy to have a simpler abstract model, like the one
I discussed in my earlier posts.  But the way the real implementations
actually work is that the world value is represented as the physical world.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.