IAN@vax1.esprit.southampton.ac.uk (03/30/89)
For some time now, I have been somewhat dismayed by the lack of positive
things being said about occam on the occam and transputer mailing lists.
Recent discussion on the mailing lists about 'what makes the transputer so
good?', reproduced in OUG newsletter No. 10, seems to have been generally
along the lines that transputers are really neat, but that occam is lousy.
While it is true that occam has limitations, I personally consider them to be
far outweighed by the advantages it has to offer.
I can't really argue that occam has not been an obstacle to the general
acceptance of transputer systems, but I would argue that this is really a
problem of education of the consumers. In this respect, although INMOS appear
to regard themselves primarily as chip manufacturers, I tend to think it would
benefit them in to invest a little effort in making occam available on
machines other than transputers. If people got hooked, they would surely want
to buy transputer chips, since they make such good occam engines, and make
distributing occam programs so easy.
For me, the most exciting and interesting thing about occam is not just that
it is a language designed specifically with parallelism in mind. Even more
important is that it based on a well defined mathematical model of
concurrency, which gives the language exceptionally clean semantics. Few other
languages can lay claim to such a combination of qualities. The mathematical
model in question is that of Communicating Sequential Processes (CSP), due to
Professor Tony Hoare [1]. Because of this formal basis, there exist a large
number of algebraic laws relating different programs which have the same
meaning. For instance, a rather simple and intuitive law is that the process
PAR
P
Q
has the same meaning as the process
PAR
Q
P
where P and Q are arbitrary processes. This equivalence can be written with
an equals sign, as
PAR PAR
P = Q
Q P
Another simple, but interesting, equivalence is that
PAR
c ! e = v := e
c ? v
where c is a channel, e is an expression, and v is a variable. A slightly
less obvious example is that
ALT
c ? x PAR
d ? y = c ? x
d ? y d ? y
c ? x
It should be emphasised that the above laws express identities between the
processes on either side of the equals sign. They are not just rough
equivalences, which break down in certain circumstances. They always hold.
Thus, laws which involve arbitrary processes (like P and Q in the first
example) are extremely general. This is to be contrasted with the semantics
of most commonly available languages, which typically contain many exceptions
and irregularities.
This is all very elegant, but so what? How does this help us? Well, it has
been shown that a set of laws exist, which completely characterise the
semantics of the language [2]. (Actually, the reference cited shows this for
occam 1, since that untyped version of the language is easier to deal with,
but it is expected that the same ideas can be extended to include occam 2). In
particular, for WHILE-free programs, it is shown that it is possible to use
the laws to transform any program into a 'normal form', containing only
assignments, IF's and ALT's (also obeying some other constraints). The
special thing about the normal form is that any two programs which are
semantically equivalent (have the same meaning) will have the same normal
form. Thus it is possible to check whether two different programs really do
the same thing! What is more, the steps to transform a program into its
normal form can be (almost) automated. If a tool existed which could check
the equivalence, or otherwise, of two programs, it would be immensely
valuable. For instance, it would enable you to check with one hundred percent
confidence that that 'small edit' really didn't change the meaning of a
program. From a slightly different standpoint, the laws could be used to make
transformations to a program, which would be guaranteed to be meaning
preserving. This could be helpful, for instance, when trying to improve its
execution efficiency.
On a more down to earth level, the formal properties of the language enable
the occam compiler to perform extremely strong checking of code, which is a
great help in making sure a program really does what you think it does. For
instance, it is the only compiler I know which actually enforces the complete
absence of variable name aliasing. This particular kind of checking is
required by the simple substitution semantics of abbreviations and procedure
parameters. On the other hand, the programmer is not prevented from doing
low level things such as accessing memory mapped peripherals, or accessing the
same machine word as more than one different type. Those things are allowed,
but treated more hygienically than in most languages, with the PORT and
RETYPES declarations, respectively. The strictness of the compiler can be
irritating at times, but, for me at least, this is outweighed by the extra
confidence I have in a piece of code which has passed its stringent
requirements.
One criticism of occam which is often raised, is that it is not recursive. It
is interesting to note that the underlying CSP model is indeed recursive, and
there is no reason in principle why a recursive version of occam could not be
implemented. No syntactic changes to the language would be necessary. The
reason the definition in the occam 2 reference manual [3] is not recursive is
simply to allow an efficient and secure implementation of the language on the
transputer. For the same reason, there is no real reason why the process count
on a replicated PAR construct could not be allowed to be variable. However,
the current definition does have the advantage that the amount of memory
needed to execute a process is known at compile time, and so there is no
possibility of a program crashing at run time, with stack or heap overflow. If
this were not the case, the program transformations mentioned above would no
longer, in general, be meaning preserving, and it would not be possible to
make use of the formal properties of the language (at least, not so easily).
Occam is not everything, of course, and I hope that we will be seeing, in due
course, an 'occam 3', containing some of the abstract data types which were
left out of occam 2 (give the guy's at INMOS a chance!). Records, more
general arrays, and an enumeration type might be expected, for instance.
Looking further ahead, what might be the line of development? It has been
said that occam is an 'assembly language' for parallel processing. This is
not meant to imply that the conventional aspects of occam are at the level of
an assembly language, as it is clearly a 'high level' language (whatever that
means) in that sense. Rather, the communication facilities provided by
channels are sufficiently primitive to allow higher level communication
constructs to be efficiently built on top of them. At the moment, it is not
entirely clear what such constructs ought to be, but when it is, a new
language will presumably be designed around them. Channels might be regarded
as the GOTO's of parallel programming, which will eventually be replaced by
more structured ideas.
In conclusion then, it is really the formal properties of occam which make it
such an interesting language, and it is the things which the occam compiler
does not allow you to do, almost as much as those which it does, that make it
such a useful tool. I look forward to further occam inspired developments,
and, in the mean time, sincerely hope that the elegance and security of the
language will come to be appreciated by a wider circle within the computing
community. By the way, I'm also a fan of TDS [4], but that, as they say, is
another story!
[1] C.A.R. Hoare, "Communicating Sequential Processes",
Prentice Hall International series in Computer Science, 1985,
ISBN 0-13-153271-5, ISBN 0-13-153289-8 PBK
[2] A.W. Roscoe and C.A.R. Hoare, "The Laws of occam Programming",
Oxford University Computing Laboratory Programming Research Group,
Technical Monograph PRG-53, February 1986, ISBN 0-902928-34-1
[3] INMOS Limited, "occam 2 Reference Manual", Prentice Hall International
Series in Computer Science, 1988, ISBN 0-13-629312-3
[4] INMOS Limited, "Transputer Development System", Prentice Hall
International, 1988, ISBN 0-13-928995-X
+-----------------------------------------------------------------------------+
| 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 |
+-----------------------------------------------------------------------------+nick@lfcs.ed.ac.uk (Nick Rothwell) (03/31/89)
In article <8903291813.AA10019@uk.ac.ox.prg> IAN@vax1.esprit.southampton.ac.uk writes: >... I tend to think it would >benefit them in to invest a little effort in making occam available on >machines other than transputers. If people got hooked, they would surely want >to buy transputer chips, since they make such good occam engines, and make >distributing occam programs so easy. 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? >For me, the most exciting and interesting thing about occam is not just that >it is a language designed specifically with parallelism in mind. Even more >important is that it based on a well defined mathematical model of >concurrency, which gives the language exceptionally clean semantics. Few other >languages can lay claim to such a combination of qualities. >... >For instance, a rather simple and intuitive law is that the process > > PAR > P > Q > >has the same meaning as the process > > PAR > Q > P 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). 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. Conversely, I can cite languages which have a full, documented, formal semantics. >On a more down to earth level, the formal properties of the language enable >the occam compiler to perform extremely strong checking of code, which is a >great help in making sure a program really does what you think it does. For >instance, it is the only compiler I know which actually enforces the complete >absence of variable name aliasing. You get that from any non-procedural language. <This particular kind of checking is >required by the simple substitution semantics of abbreviations and procedure >parameters. On the other hand, the programmer is not prevented from doing >low level things such as accessing memory mapped peripherals, or accessing the >same machine word as more than one different type. Those things are allowed, >but treated more hygienically than in most languages, with the PORT and >RETYPES declarations, respectively. The strictness of the compiler can be >irritating at times, but, for me at least, this is outweighed by the extra >confidence I have in a piece of code which has passed its stringent >requirements. 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. >One criticism of occam which is often raised, is that it is not recursive. It >is interesting to note that the underlying CSP model is indeed recursive, and >there is no reason in principle why a recursive version of occam could not be >implemented. No syntactic changes to the language would be necessary. 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. >Occam is not everything, of course, and I hope that we will be seeing, in due >course, an 'occam 3', containing some of the abstract data types which were >left out of occam 2 (give the guy's at INMOS a chance!). Records, more >general arrays, and an enumeration type might be expected, for instance. >Looking further ahead, what might be the line of development? I'd actually love to see an OCCAM with a polymorphic/abstract type discipline. >It has been >said that occam is an 'assembly language' for parallel processing. This is >not meant to imply that the conventional aspects of occam are at the level of >an assembly language, as it is clearly a 'high level' language (whatever that >means) in that sense. It's an assembly language in that memory is viewed as a linear object, with no recursion, dynamic management of objects, abstraction, etc. More importantly, it's a transputer assembly language because of the mapping between what OCCAM does and what the hardware does. When this mapping becomes nontrivial, then you have a higher level language. >[1] C.A.R. Hoare, "Communicating Sequential Processes", > Prentice Hall International series in Computer Science, 1985, > ISBN 0-13-153271-5, ISBN 0-13-153289-8 PBK > >[2] A.W. Roscoe and C.A.R. Hoare, "The Laws of occam Programming", > Oxford University Computing Laboratory Programming Research Group, > Technical Monograph PRG-53, February 1986, ISBN 0-902928-34-1 > >[3] INMOS Limited, "occam 2 Reference Manual", Prentice Hall International > Series in Computer Science, 1988, ISBN 0-13-629312-3 > >[4] INMOS Limited, "Transputer Development System", Prentice Hall > International, 1988, ISBN 0-13-928995-X [5] Robin Milner, "A Calculus of Communicating Systems", Springer-Verlag, 1980, ISBN 3-540-10235-3 (couldn't resist that plug...!) >| Ian Glendinning JANET: ian@UK.AC.soton.esp.v1 Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
pick@sdsu.UUCP (Dan Pick) (04/03/89)
As a novice user of occam just getting my feet wet, I find it irritating that the language doesn't include a character data type, and that all the I/O procedures included in the userio library refer to reading, writing, and echoing parameters of type INT char. These are muddy waters!
jxdl@lanl.gov (Jerry DeLapp) (04/04/89)
In article <8903291813.AA10019@uk.ac.ox.prg>, IAN@vax1.esprit.southampton.ac.uk writes: [much text deleted] > I can't really argue that occam has not been an obstacle to the general > acceptance of transputer systems, but I would argue that this is really a > problem of education of the consumers. Whenever I see someone use the phrase a "problem of education of consu- mers" I immediately wonder why it's a problem in the first place. As a person who has attempted "education of consumers" with respect to the advantages of occam, I feel that what really needs to happen in this case is "education of vendors." (And I believe this is true of just about every other case where "education of consumers" is the purported to be the "problem"). In my case, I suffered through learning the folding editor, ODS, TDS, OCCAM 1, OCCAM 2, five hour compiles, etc. because I was paid to do it by my company (In fact, I'm about to go do it again GAG :-). In the process, despite all the shortcomings of the software, I came to love the idea of the transputer. I then took on the duty of attempting to convince our customers that they should make the same effort on their own time, without much luck. Most of them decided that they'd wait for "real languages" (C and FOR- TRAN) before they'd try the transputer. The one scientist I worked with who attempted to use OCCAM worked for over six months on his application and never got it to work (and he knew what he was doing). We eventually got a C compiler for our system, and a similar application was up in two weeks. The root of the real "problem" as I see it is that any vendor of a new product (languages, chips, software) needs to keep in mind the follow- ing: 1) Most of the people who program and use computers are not computer scientists. They are not interested in learning new languages, new hardware, or in the intricacies of formal transforms of programs. They have a real world problem that they want to solve using the com- puter. In the scientific and engineering marketplace (the traditional users of new experimental systems) the lingua franca is FORTRAN, and, to a much lesser extent, C. 2) There is a "threshold of pain" that a person will not go beyond in his efforts to achieve a goal unless the benefit is clear. With respect to a new language, typically a scientist will not go to the effort to learn it unless his problem will be solved much much faster than his currently available familiar options. Most scientists I've talked with quote that their application must run 10 times faster be- fore they'll go to a major effort. Also, the scientist won't go to the effort unless your option is 10 times faster FOR THE SAME COST as his fastest available familiar option. The only exception to this rule that I've seen is when the problem simply can't be solved with available familiar options. 3) Before expending the effort of learning a new language/product/chip to solve a problem, it must be demonstrable that the item will have long term utility. e.g. will what I learn be valid 2 years from now, will my application be able to run on new wowie machine XYZ without a similar learning effort, etc. This is why UN*X, FORTRAN, and C are so successful, and why most people only program in assembler when they have to. [more deleted] > I tend to think it would > benefit them (INMOS) in to invest a little effort in making occam available on > machines other than transputers. If people got hooked, they would surely want > to buy transputer chips, since they make such good occam engines, and make > distributing occam programs so easy. [a very good description of the computer science advantages of occam deleted] I very much agree with the above statement, however I don't know of any instance of a VENDOR SPECIFIC and VENDOR DRIVEN language having long- term utility as a programming vehicle for general users. (People only program in assembler if they have to, and, official definitions aside, if it only runs on platform X, it's assembler, OCCAM included). Also, I'd contend that what would sell is transputer based systems, not chips, and it's highly unlikely that the systems would sell well unless the transputer world can agree on a paradigm for system software. Again, this is why UN*X is so popular. People love being able to run the exact same software on many different platforms. UN*X provides the system software paradigm that makes this possible. In my opinion, INMOS has fallen down on all three of the points I made above. In the case of point 1, the OCCAM "time to solution" is far too high. (Who cares if your problem is solved in 10 hours instead of 10 days, if it took you six months to port the application?) To use OCCAM, you not only have to learn a new language, but a new editor, execution environ- ment, linker, YOU HAVE TO BUY A TRANSPUTER BOARD just to develop code and, there's no system software to speak of available (e.g. no de- bugger). In my opinion, TDS is a lousy design for implementing an in- teresting new language (are you listening David May? :-). INMOS tried to roll far too many "neat ideas" into the package. Each idea taken on its own (e.g. the folding editor) has merit, but adding learning them to the task of learning a new language was a mistake (IMHO :-). In the case of point 2: The items above make the "level of pain" very high for a non computer scientist, and INMOS has not adequately demon- strated the necessary performance improvements to induce people to cross the threshold. (I'm sorry, but one of those toy PC boards just doesn't run 10X faster than a CRAY :-). I'd suggest that, in addition to promot- ing OCCAM on other platforms, INMOS ought to build and market product out of transputers a little larger than boards to go into PCs. Make it big enough that it's 10x faster than the fastest Cray out there now. The world would drool for it. In the case of point 3: It's not at all clear here in the US that the transputer has a future (please no flames, I am a true believer in parallel processing as represented by the transputer). INMOS has been scaling back it's US efforts. No one has built a big transputer machine that made a big splash. OCCAM only runs on transputers. INMOS appears to be uninterested in promoting OCCAM as a more general programming language. It's very difficult to demonstrate to a non-computer scien- tist how OCCAM is better than, say, C with some extensions for parallel- ism (and frankly, I'm not convinced that it is, I'd like to see threads (a la MACH from CMU) implemented in C for the transputer). -- _ /| The opinions here are my own, and even I don't agree with me :-) \'o.O' I am not an employee of LANL, I just use their computers. =(___)= I stole the .sig file, but I did not shoot no deputeeee. U Bill sez: AAAAK! PHHHT! jxdl@lanl.gov
IAN@vax1.esprit.southampton.ac.uk (04/10/89)
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 | +-----------------------------------------------------------------------------+
nick@lfcs.ed.ac.uk (Nick Rothwell) (04/13/89)
In article <8904101227.AA05713@uk.ac.ox.prg> IAN@vax1.esprit.southampton.ac.uk writes: >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. Fair enough. I was probably getting a little wound up by the way that OCCAM keeps getting referred to as a "calculus", as if there is something magically formal about it that sets it completely apart from other languages. It *does* have some nice (and important) semantic properties, but I certainly would not call it a formal language; it is a programming language, like you say, nothing more, nothing less. 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. 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. 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? >| Ian Glendinning Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.
ben@tasis.utas.oz (Ben Lian) (04/16/89)
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 -----------------------------------------------------------------------