🚀 go-pugleaf

In article <1663@etive.ed.ac.uk>
Nick Rothwell <mcvax!ukc!etive!lfcs!nick@net.uu.uunet> 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                       |
+-----------------------------------------------------------------------------+