🚀 go-pugleaf

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.

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!

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