world as value

[Erik Zuurbier]

Adrian,
This is not the first time you inspired me to think further about Clean.
Earlier, you made me wonder if you can still call a function 'purely
functional' if one of its arguments is abstract (such as the *World). Now
it was your posting containing "From a pragmatic point of view, the issue
which really worries me is BLOCKING" and "I have an automated factory
controlled from a Clean Program which is capable of making anything I
desire. I desire a new bicycle and a new helicopter. (etc)"

I think I can add some clarification to your idea (or else a different view
on it). Indeed we have available predefined functions that split off unique
subenvironments, such as fopen, stdio and... well I can't find any other
examples. Particularly for fopen, the implementation makes sure that the
sub-environments don't interfere with one another. Also, there is a
run-time check to make sure the same file cannot be opened when it is
already open. Effectively, that means the whole file is locked when one
(part of a) program opened it for writing.

Now imagine I would like to implement a personnel-database system in Clean.
The whole data-part of the database could be in one file, but then, if one
user was busy updating data of Mr. X in this database, the whole file would
be blocked for the rest of the company, even from access by a user who
would only update data of an unrelated Mr. Y. Commercial database systems
don't (b)lock on the file level, because this is totally unacceptable. Some
lock on a page level or on a record level. So effectively I cannot
implement an acceptable database system in Clean. Correct? I would like to
be able to split off a sub-environment of Mr. X and have the operating
system guarantee that Mr. X's place in the (super)environment stays, that
nobody else will split it off while I work on it and that updates on the
set of subenvironments do not mutually interfere. (BTW, I have read about
the approach in Peter Achten's PhD where he treats the file system as a
server.)

A different example. We have a big matrix, which is unique for efficiency's
sake. Now imagine there are various sub-matrices (slices?) which I would
like to update, while I know that the updates don't interfere. So I would
like to split off unique sub-matrices and be able to work on these
concurrently. I would also like the operating system to take care that
updates do not interfere, etc.

Is it possible generally, to give the Clean-user a function to split off
unique sub-environments or sub-structures from any unique object? It may
not be easy, but I hope my examples will make it clear it will be needed in
the end.

In the general case, it will be impossible to have the compiler find out if
updates on one sub-structure interfere with others. Clean has two
approaches to that. The first one is introducing run-time checks. That is
what already happens with array boundaries. The other is putting the
responsibility on the programmer. That is what happens with array
boundaries when the user disables the run-time checks. Programmers are not
generally tempted to abuse this latter possibility to create non-functional
programs in Clean, as the behaviour of matrices peeking and poking outside
their bounds is (almost) impossible to predict. Yet, it is a door open to
non-functional programming in Clean.

Another door is the use of ABC-code in a 'code {...}' construct that I can
freely use anywhere in my Clean program. This also allows me to create
non-functional behaviour in Clean. In other words, the creators of Clean
already silently rely on programmer decency to back up their claim that
Clean is purely functional.

This being the case, they could perhaps create a general function to split
off unique sub-environments and sub-structures and add a compiler-option to
add or not add run-time checks on mutual interference.

Regards,
Erik Zuurbier