🚀 go-pugleaf

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    <Atlantic Ocean>!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
-----------------------------------------------------------------------