Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ames!sun-arpa!male!pitstop!sundc!seismo!uunet!munnari!murtoa.cs.mu.oz.au!ditmela!diemen!tasis!ben From: ben@tasis.utas.oz (Ben Lian) Newsgroups: comp.sys.transputer Subject: Re: what makes occam so good? Message-ID: <917@tasis.utas.oz> Date: 16 Apr 89 14:38:46 GMT References: <8904101227.AA05713@uk.ac.ox.prg> <1756@etive.ed.ac.uk> Organization: Elec Eng & Comp Sci, Uni of Tasmania, Australia Lines: 91 In article <1756@etive.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > Actually, I quite like OCCAM. It provides a good way of building frameworks >and mechanisms to handle the concurrent part(s) of an application. However, >it totally fails to provide some of the important aspects of a software >system: recursion, abstraction, data structuring, etc. My apologies if the following sounds like self-promotion but I thought that some people might be interested. When occam first appeared on the scene, I was happy with the way it reflected the CSP model, but I wasn't happy with the lack of high level facilities. So a couple of years ago I decided to design my own CSP-based language. After a long and often painful gestation period I finally produced IMPALA (IMperative PArallel LAnguage). It contains a fairly simple but powerful type system in which one can create structured types (arrays, products, unions), and in which the numeric types form a subtype hierarchy. There are also facilities for the implementation of abstract data types. Other features include two kinds of subprograms, processes and functions, which may be generic, and functions may also be recursive. I won't bore you with further gory details except to say that a compiler is currently under development, resident on a VAX/UNIX system, cross-compiling for the transputer. Designing and implementing a language to get what I want is, I guess, somewhat masochistic. It's definitely doing things the hard way! > In a recent project >we tied 20000 lines of C (a compiler for an abstract language, abstract >code generator, interpreter, and so on) with some OCCAM to provide a >communications base. Writing the compiler in OCCAM would have been a virtual >non-starter. Writing it in C was bad enough, given that the prototype was >in ML. Oh yes! I mentioned in an earlier posting that I have an occam compiler written in occam, and that it was not a sight for the faint of heart. A little bird in INMOS tells me that the current occam compiler supplied as part of the TDS version D700D is written in occam. For various reasons, the next generation of occam compilers will be, umm, are, written in C. The reason given directly is that of portability, but I suspect that maintenance is also a bit of a headache. By the way, don't get me wrong -- I'm not knocking occam. It has its place in the scheme of things. > The main reason for OCCAM's failure, I think, is the closed world >philosophy that went along with it. INMOS wanted everybody to program >entirely in OCCAM under the TDS on their Sage computers. Everything else >was "alien" - even files. We threw the OCCAM out of our project and used C >instead, because OCCAM's little world was so completely nonstandard and >different to everything else. Using C and the 3L tools, we can drive the >development process from a Sun. Had INMOS brought out a "batch" OCCAM >compiler, and believed in conventional machines and file systems, things >might have been different. What do other people feel? Yes, agreed. The TDS seems to only get in the way. Maybe I've been using UNIX for too long and can't get used to a different way of working, I don't know. When I wanted to play around with the transputer instruction set, I found myself preferring to use the assembler in Logical System's Logical System's Transputer Toolset (great stuff!) rather than use occam2's GUY construct. >Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. > nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick I might just add that readers interested in seeing the sort of program transformation possible with occam programs should try to get hold of the Oxford PRG technical report by Bill Roscoe and Tony Hoare titled "The Laws of Occam Programming" (Technical monograph PRG-53, February 1986). Admittedly, the language used is a subset of occam 1 -- timing, priority, vectors, constants, replicators and named processes are omitted -- but it is interesting nonetheless. The ability to transform a program/construct into a semantically equivalent one is is useful for "...transforming programs to make them more efficient, and transforming programs to a restricted syntax for special applications." The latter is demonstrably feasible, while the former and the more general goal of proving programs correct are still somewhat problematical. Ben Lian ----------------------------------------------------------------------- Benjamin Y H Lian ACSnet: ben@tasis.utas.oz Dept. of EE & CS ARPA : ben%tasis.utas.oz.au@uunet.uu.net University of Tasmania BITnet: munnari!tasis.utas.oz!ben@ GPO Box 252C uunet.uu.net Hobart, Tasmania 7001 UUCP : {enea,hplabs,mcvax,uunet,ukc}! A U S T R A L I A munnari!tasis.utas.oz!ben -----------------------------------------------------------------------