Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!vax1.esprit.southampton.ac.uk!IAN From: IAN@vax1.esprit.southampton.ac.uk Newsgroups: comp.sys.transputer Subject: Re: what makes occam so good? Message-ID: <8904101227.AA05713@uk.ac.ox.prg> Date: 10 Apr 89 13:27:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 83 In article <1663@etive.ed.ac.uk> Nick Rothwell writes: >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? The occam model of concurrency maps well onto any loosely coupled multiprocessor system. The code running on each processor can be written in the sequential subset of occam. >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). Yes, but most languages don't have very many such rules, and they usually have semantic constraints. In occam, these rules *define* the semantics. For instance, taking your example, in occam (A+B) = (B+A) is *always* true, by definition - there are no side effects. >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. No doubt Milner's CCS is indeed a more general tool to describe a wide variety of models of concurrent behaviour, but that is not the intention of occam. It is intended to be a programming language. See the discussion in the last chapter (last section, I think) of Hoare's CSP book. >You get that from any non-procedural language. True. I like non-procedural languages too. >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. I agree. That is why PORTs should always be used to access memory mapped peripherals. The address of each port is fixed, and the compiler performs the same useage checking as if the port was a channel. RETYPES allows the memory allocated to a variable or array to be accessed under the guise of a new variable or array of a different type. There is no aliasing, as the old name goes out of scope. The total size (in bytes, words or whatever) of the RETYPED variable can not exceed that allocated for the original one. The major uses of this facility are to allow the programmer to construct 'heaps' of objects of different types, or to implement record structures, while preserving type checking. The need for this would go away if occam supported more abstract data types, as one day I hope it will. >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. True. I must admit I glossed over that, but I didn't actually say that the semantics of the language would be unaltered. While at the moment, a name does not come into scope until its declaration is complete, it would have to come into scope at the beginning of its declaration to permit recursion. There is also the issue of how you get mutual recursion. For instance, if PROC A calls B() and PROC B calls A(), then whichever way round you declare them (at the same level) one of the calls will refence a name that is out of scope. The usual solution is to alter the syntax to allow a 'stub' declaration before the main one, just declaring the procedure name and its parameter list. >I'd actually love to see an OCCAM with a polymorphic/abstract type discipline. So would I. +-----------------------------------------------------------------------------+ | Ian Glendinning JANET: ian@UK.AC.soton.esp.v1 | | Fidelio Software GmbH BITNET: ian%UK.AC.soton.esp.v1@AC.UK | | Widenmayerstrasse 6 UUCP: ...!mcvax!sot-cm!igl | | D-8000 Muenchen 22 other: ian@v1.esp.soton.AC.UK | | West Germany Phone: +49 89 2123080 | +-----------------------------------------------------------------------------+