Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!etive!lfcs!nick From: nick@lfcs.ed.ac.uk (Nick Rothwell) Newsgroups: comp.sys.transputer Subject: Re: What makes occam so good? Message-ID: <1663@etive.ed.ac.uk> Date: 31 Mar 89 13:01:18 GMT References: <8903291813.AA10019@uk.ac.ox.prg> Sender: news@etive.ed.ac.uk Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell) Organization: LFCS Enya Admiration Society Lines: 127 In article <8903291813.AA10019@uk.ac.ox.prg> IAN@vax1.esprit.southampton.ac.uk writes: >... I tend to think it would >benefit them in to invest a little effort in making occam available on >machines other than transputers. If people got hooked, they would surely want >to buy transputer chips, since they make such good occam engines, and make >distributing occam programs so easy. OCCAM has a particular model of concurrency which happens to map fairly closely to the way you plug transputers together, and their hardware capabilities. If you try to implement it on hardware which doesn't give you these things, you have to emulate, and take a huge performance hit. Look at the OCCAM evaluation kit, or whatever. I agree that it was a good idea to put that out in advance, but I don't know how many people were converted to what they saw, plus the promise of fast hardware. Any comments? >For me, the most exciting and interesting thing about occam is not just that >it is a language designed specifically with parallelism in mind. Even more >important is that it based on a well defined mathematical model of >concurrency, which gives the language exceptionally clean semantics. Few other >languages can lay claim to such a combination of qualities. >... >For instance, a rather simple and intuitive law is that the process > > PAR > P > Q > >has the same meaning as the process > > PAR > Q > P These kinds of rules are just simple rewrite rules on abstract syntax. You get them in any language, where A+B == B+A (side-effects apart). I don't see anything which makes OCCAM a formal "calculus" of any kind. I haven't seen any work which shows it to be mathematically rigorous. For a formal approach to concurrency and behaviour, I'd rather look at something like Milner's Calculus of Communicating Systems which has concepts of observational and behavioural equivalence. Conversely, I can cite languages which have a full, documented, formal semantics. >On a more down to earth level, the formal properties of the language enable >the occam compiler to perform extremely strong checking of code, which is a >great help in making sure a program really does what you think it does. For >instance, it is the only compiler I know which actually enforces the complete >absence of variable name aliasing. You get that from any non-procedural language. required by the simple substitution semantics of abbreviations and procedure >parameters. On the other hand, the programmer is not prevented from doing >low level things such as accessing memory mapped peripherals, or accessing the >same machine word as more than one different type. Those things are allowed, >but treated more hygienically than in most languages, with the PORT and >RETYPES declarations, respectively. The strictness of the compiler can be >irritating at times, but, for me at least, this is outweighed by the extra >confidence I have in a piece of code which has passed its stringent >requirements. If you can access things by address, then you can get aliasing problems, like those you dismissed above. Low-level features are often necessary, but they *always* violate your language model and invalidate formal resoning. >One criticism of occam which is often raised, is that it is not recursive. It >is interesting to note that the underlying CSP model is indeed recursive, and >there is no reason in principle why a recursive version of occam could not be >implemented. No syntactic changes to the language would be necessary. Please clarify. Suppose I define a process/procedure/whatever called FOO. I then define another one called FOO, and inside that, reference FOO. If my OCCAM system shifts from being non-recursive to being recursive, my program breaks. Recursion reflects the name-space semantics of the language. >Occam is not everything, of course, and I hope that we will be seeing, in due >course, an 'occam 3', containing some of the abstract data types which were >left out of occam 2 (give the guy's at INMOS a chance!). Records, more >general arrays, and an enumeration type might be expected, for instance. >Looking further ahead, what might be the line of development? I'd actually love to see an OCCAM with a polymorphic/abstract type discipline. >It has been >said that occam is an 'assembly language' for parallel processing. This is >not meant to imply that the conventional aspects of occam are at the level of >an assembly language, as it is clearly a 'high level' language (whatever that >means) in that sense. It's an assembly language in that memory is viewed as a linear object, with no recursion, dynamic management of objects, abstraction, etc. More importantly, it's a transputer assembly language because of the mapping between what OCCAM does and what the hardware does. When this mapping becomes nontrivial, then you have a higher level language. >[1] C.A.R. Hoare, "Communicating Sequential Processes", > Prentice Hall International series in Computer Science, 1985, > ISBN 0-13-153271-5, ISBN 0-13-153289-8 PBK > >[2] A.W. Roscoe and C.A.R. Hoare, "The Laws of occam Programming", > Oxford University Computing Laboratory Programming Research Group, > Technical Monograph PRG-53, February 1986, ISBN 0-902928-34-1 > >[3] INMOS Limited, "occam 2 Reference Manual", Prentice Hall International > Series in Computer Science, 1988, ISBN 0-13-629312-3 > >[4] INMOS Limited, "Transputer Development System", Prentice Hall > International, 1988, ISBN 0-13-928995-X [5] Robin Milner, "A Calculus of Communicating Systems", Springer-Verlag, 1980, ISBN 3-540-10235-3 (couldn't resist that plug...!) >| Ian Glendinning JANET: ian@UK.AC.soton.esp.v1 Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.