Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!uokmax!munnari.oz.au!metro!kwanon!andy
From: andy@research.canon.oz.au (Andy Newman)
Newsgroups: comp.sys.transputer
Subject: Re: RE Anarchic Protocol ANY (occam2)
Message-ID: <1991May18.025524.5909@research.canon.oz.au>
Date: 18 May 91 02:55:24 GMT
References: <29382.9105161115@prg.oxford.ac.uk>
Sender: andy@research.canon.oz.au (Andy Newman)
Reply-To: andy@research.canon.oz.au (Andy Newman)
Organization: Canon Information Systems Research Australia
Lines: 33

In article <29382.9105161115@prg.oxford.ac.uk> HALLAM@physics.oxford.ac.uk ("Phillip M. Hallam-Baker") writes:
>It would be nice to have a stripped down version of occam with a more
>usable typing mechanism which would handle records. This should be integrated
>to the channel PROTOCOL declarations.

I don't think that it should be necessarially "stripped-down". What
would you want to remove? Adding user defined types (definitely
structures, enumerations would be nice and sub-ranges would help
compile time checking) to occam would take it out of the 1950's.
Of course user-defined types should be allowed in PROTOCOL's, just
as the primitive types are allowed. The hardest problems with
structures is defining the syntax of field selection (the '.' has
been stolen, rats) and handling variants (if full Pascal-like
structuring is wanted). Enumerations and sub-ranges would seem
to be excellent candidates for occam due to the extra compile
time checking they can provide.

In a large occam project I was involved in (10 people, 200K+
lines of code) one of the greatest problems was mixing up
parameters to procedures. The occam compiler can't catch this
as they're all INT (or something) and doesn't know the intent
of the programmer. Even a method of defining new names for
types and some checking of type usage would stop this.

Just what is happening to occam? I met David May several years ago
and he discussed some of the features he wanted to incorporate
in occam-3 (modules, user defined types, etc...), is there any
information available on this?

On another track has anyone thought about Concurrent-C (the Bell
Labs one not the occam'ised C's you can get) on Transputers?
-- 
Andy Newman (andy@research.canon.oz.au) Canon Info. Systems Research Australia