Newsgroups: comp.sys.transputer
From: A.Kruse@nikhef.nl (Andres Kruse (NIKHEF),1c/137,2909)
Subject: Re: OCCAM3 (was :- Revision of occam 2 Referenc
Organization: NIKHEF - Amsterdam
Date: 9 Aug 1994 19:59:12 GMT
Message-ID: <328n6g$24v@dscomsa.desy.de>

In article H7n@info.bris.ac.uk, md@pact.srf.ac.uk (Mark Debbage) writes:
> Peter Ivimey-Cook (peteric@gonzo) wrote:

[snip] 

> : 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.

One should then also forbid PLACEing of variables in a FUNCTION, no ?

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

-- Andres (A.Kruse@nikhef.nl)
















