world as value

[P.R. Serrarens]

Adrian Hey wrote:
> 
> On Thu 15 Jul, P.R. Serrarens wrote:
> > Exactly.
> 
> Or maybe not.. Although a general compiler solution to this problem
> is not possible, I think it would be possible to have a system which
> allowed artificial dependency to control the order in which things happened
> if it was important. In fact that's all world as value really is, in
> my humble opinion. Unfortunately, it seems an especially constraining
> form of artificial dependency because it requires all actions to be chained
> together in a linear sequence.

I don't quite see what you mean here: what is this artificial dependency and
when it is important? How do you (or the runtime system) decide this?
 
> Suppose instead, we had something like a 'non-deterministic do' which
> was basically a collection of actions (_not_ functions) which could be
> performed in any order we (the scheduler) like or concurrently, subject to
> satisfying dependency constraints (real or artificial). Of course this
> collection of actions would not be a proper value, and the
> 'non-deterministic do' would not be a function, so any language which
> contained such a construct would not be purely functional. Also, since such
> a scheme would never explicitly reference the environment being manipulated,
> it also need not be a proper value. It could simply be 'the world', and
> so may contain all sorts of nasties like mutable non-unique values and
> 'self changing' values (like time perhaps).

This goes rather far, even I haven't though about that yet :-)

So as to make this concrete: you have a collection of action, with type *env
-> *env (I am not specifying what the environment is, it is not important) and
put them into a list, for example:

:: Actions :== [ *env -> *env ]

You do not specificy an ordering, the ordering in the list does not say
anything about the order of the actions. (Maybe a set would be better here).

Now you can execute these actions by using the function <doActions>:

doActions :: Actions *env -> *env

A function may then look like:

f :: *env -> *env
f e =
   doActions [
      action1,
      action2
      ]
where
    action1 :: *env -> *env
    action2 :: *env -> *env


One problem I see here is how to use functions returning a result, one cannot write:

f e = doActions [
    r = action1,
    action2 r
    ]
where
   action1 :: *env -> (a, *env)
   action2 :: a *env -> *env

For example.

Another point can be the implicit dependencies between the actions, but with
this constuction you say that you do not care about this and the environment
passed to <doActions> will give you the took to make it semantically correct.

Again, this is a rather 'drastic' idea and may work well, BUT it may be very
dangerous in the hand of an inexperienced programmer! And that is the biggest
problem I have with it. In my opinion, constuctions which are potentially
dangerous should be possible, but in a way that _makes_ you think hard about
the dangers. I don't think the construction above does that.

-- 
Pascal Serrarens
Concurrent Clean developer
University of Nijmegen, NL