world as value

[Adrian Hey]

On Mon 19 Jul, P.R. Serrarens wrote: 
> 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?

Examples of artificial dependency...
 1- World as value (including Haskell IO monad), in my humble opinion
 2- [] messages in Pict
 3- Concurrent Haskell MVars (although since these may be used to pass
    values, perhaps the dependancy often isn't artificial.)

I'm not sure which of the above I prefer or something entirely different,
but I'm pretty sure example 1 would not be my prefered choice.
 
> 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:

I'm not sure I agree with you here. In my view an action is _not_ a function.
It may return values, and its effects and results may well depend on the exact
state of the environment(s) it manipulates, but to regard it as a function of
some world or environment value is the the wrong way of thinking about it,
because I don't think IO environments are proper values.
 
> Now you can execute these actions by using the function <doActions>:

Again no, the 'non-deterministic do' (doActions) would not be a function.
It would be a syntactic construct which translated user friendly notation
(yet to be specified) into something like Pict perhaps.

I'm not really sure how such a scheme would really work in practice or how
it could be implemented without suffering a 'thread explosion'. I'm just
thinking about it, and the unnecesary (in my opinion) linearity of
environment as value IO.

I think you over estimate the dangers, a lot depends on how the environments
which the actions manipulate are constructed (and how difficult/easy it
is to introduce controls for sequencing if required). As far as I can
see, given 'well constructed environments' the worst that's likely to
happen is some actions get blocked, but only those actions which really
need to be blocked.

Consider the independent environments approach to say.. a printer and a
filing system. You might like to consider them independent, but in reality
both the printer and the disc drive are sitting on a SCSI bus (for example).
The SCSI host adapter is controlled by a process (environment). Both the
printer driver process (environment) and the filing system process
(environment) use the SCSI process (environment) to get anything done.
So in what sense are they independent? Yet Clean (presumably) would consider
them as independent and printer and file system operations could be performed
concurrently. I think this is perfectly safe, but only because the
environments concerned are 'well constructed', if you see what I mean.

It occurs to me that one solution to the sequencing problem (for things like
files) would be to arrange that all file actions took a unique token and
returned that token as part of the result. This is what Clean really does
isn't it?. That way the user would be forced to consider the order in which
things were done. But for environments in which the order didn't matter,
you could leave the token out. Of course the other effect of such a token
(in lazy Clean) is to force file actions to occur by 'evaluating' the
token in the file close function. For tokenless environments one could not
rely on this effect, so the 'non-deterministic do' would have to be
imperative rather than functional (another good reason for not regarding
actions as functions I think).  

Regards
-- 
Adrian Hey