Newsgroups: comp.sys.transputer
From: md@pact.srf.ac.uk (Mark Debbage)
Subject: Re: OCCAM3 (was :- Revision of occam 2 Referenc
Organization: University of Bristol, England
Date: Tue, 9 Aug 1994 12:34:56 GMT
Message-ID: <Cu9pM9.H7n@info.bris.ac.uk>

Peter Ivimey-Cook (peteric@gonzo) wrote:
: Andy Rabagliati (andyr@wizzy.com) wrote:

: : If you would like to post a small example, we could look at it.
: : Remember, PAR is illegal inside a FUNCTION. Maybe they already fixed it
: : in OCCAM3.

: Anyone got any ideas *why* PAR is illegal inside a function. Was it just
: too complex a case to support? Or is there a valid mathematical reason?
: I understand that FUNCTIONS are supposed to be pure (side-effect free),
: but adding PAR wouldn't affect this, surely.

: Peter IC.

If you have PAR, then you will want channels too. You can then build functions
that deadlock. If you have channels, then you will want alternation and maybe
timers. You can then build functions that give non-deterministic results. Yuk.

Some people think that allowing WHILE inside a function was a pretty bad 
move, since that allowed you to write live-locked functions. This means that
there can be no guarantee that arbitrary occam expressions will ever complete.
In CSP terminology, this means that occam expressions can diverge. Yuk.

If you like the formal side of occam, things like this really matter.

Mark.

