🚀 go-pugleaf

   Elegant tool for expressing parallelism? definitely.
   Elegant tool for expressing everything else? definitely not.

   The Occam syntax leaves a lot to be desired:


Agreed.

   (1) It is not free formatted; I thought the days of counting columns 
       were over.

Actually, I think this is an advantage. Have you ever looked at the PASCAL
source of TeX, as it is produced by Tangle? Incredible what a "freeformatted"
language will allow! Why do you expect any decent development environment
to have a prettyprinter, and people can never agree on the rules to give it?
Why do we actually have bugs _found_ by looking at prettyprinted listings
("ah, damn, I'd thought I'd {opened|closed} thos braces seventeen lines
{before|later}!")? Naa, I'll take the indentations and a decent folding editor
any time  it's even good for my laziness, as a single return saves me all the
BEGINs and ENDs and ;s.

   (2) I fail to see the advantage of having no operator hierarchy or default 
       data types:

       why write this:

	  (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32)))  4.0 (REAL32)

       and count brackets when all I'm trying to do is:

	  1.0 + 2.0*3.0  4.0

Hmm, yes, the operator hierarchy  I tend to agree with you. On the other
hand, who _can_ remember the hierarchy in C or C++? But a little syntactic
sugar would indeed be nice. But please leave out the default data types. 
Look at the mess you get into when you try to convert a C programme to a 
64 bit architecture  all those constants you forgot to tack an L onto,
for instance. Of course, all those (REAL32) are tiresome, but then you have
those nice VALs...

   (3) Is it really elegant to write this:

	IF
	  var1 < 1.0 (REAL32)
	    SEQ
	      var1 := 2.0 (REAL32)
	      var2 := 2.0 (REAL32)
	  TRUE
	    SKIP

	instead of  If( var1 < 1.0 ) Seq{var1 = 2.0;var2 = 2.0;}

No, it's not elegant, but since when is elegance of consideration when
designing a language :)? But it does give nice formal semantice to the
thing. I think, however, that the default should have been TRUE SKIP instead
of TRUE STOP.

   > On a similar note the TDS, like every new and elegant code managing tool;
   > once one is fluent with it's workings, has its own continually growing set
   > of advantages over traditional editors.

   I think I'll complain about this one too :)

   TDS is not a bad tool; it does have a reasonably good editor and file management
   system. My objection is why?. Who needs a new editor?; I mean just how many 
   ways can you do a cutandpaste operation!. Personally I like to keep the
   option of using any editor I wish (this may ore may not be origami) and I 
   like to have more direct control over the files on my disk. As soon as the 
   toolset came out, I gladly converted away from the TDS.

Actually, I think the control of disk files is what the TDS does best. When
we converted our main Occam programme from TDS to the toolset, a collegue
spent several days of labour (as in GULAG) to produce the makefile. And every
time you add a file to the thing, you start thinking about the dependencies
and what you have to add to the makefile. None of that with the TDS. On the
other hand, developing with multiple authors is that much harder, and some
sensible versioning system would have enhanced the value of the TDS much.

 Jan Vorbrueggen
 jan@neuroinformatik.ruhrunibochum.de

In article <2490@news.cerf.net>, jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:

> (2) I fail to see the advantage of having no operator hierarchy or default 
>     data types:

Well, the justification I see is that if there's no operator
precedence, then you *can't get it wrong*. I get the impression that a
lot of bugs in C programs are caused by people forgetting the
precedence rules in if statements and the like.

Other features of occam seem to suggest that limiting the scope for
introducing errors by was a goal in its design (no line terminator
character, one statement per line, strict indentation, no fall-through
in an IF statement etc).

IMHO, a language that helps you get it right first time is a Good Thing.

-- 
Scott Telford, Dept of Computer Science,      electric mail: s.telford@ed.ac.uk
University of Edinburgh, Mayfield Rd, Edinburgh, EH9 3JZ, UK.
------- Rollin' over like a big, big cloud/Walkin' out in the Big Sky! --------

This is the official INMOS position on occam development.

PLEASE do not e-mail me about this; I am too busy.

INMOS OCCAM POSITION
====================

13th May 1992.

INMOS are fully committed to supporting the occam programming language,
and believe that for important classes of application occam 2 is the best
language for its customers to use.

The advanced development tools including an X-windows based debugger,
a profiler and a message routing configurer will all support occam 2
programming.

An occam 2 toolset for the T9000 will be available when the T9000 is available.
This will be exactly source compatible with the occam 2 system in the current
occam 2 toolset.  At the configuration level only the hardware description
will need changing to describe the T9000 hardware, the rest of the
configuration description will be exactly the same.

INMOS expects to release an optimising occam 2 compiler with full dataflow
optimisations in 1993.  In this release the occam 2 language will be
extended to support the following new features :-

 - User defined types
 - Records
 - Remove requirement for explicitly typing literals
 - Allow arithmetic on BYTE types
 - Allow FUNCTIONs to return fixed length arrays
 - Permit the dropping of FROM and FOR in segments of arrays

This represents the first phase of the occam 3 development based on
Geoff Barrett's draft language specification.

INMOS is also planning a longer term compiler development programme based on
ANDF technology.  A second phase of development addressing modularity
and sharing will be undertaken in the context of this development and will
lead to the availability of native occam 3 compilers for a wide range of
different computer architectures.

Signed: Ian Pearson, David May, Tony Debling.


---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>
>Actually, I think the control of disk files is what the TDS does best. When
>we converted our main Occam programme from TDS to the toolset, a collegue
>spent several days of labour (as in GULAG) to produce the makefile. And every
>time you add a file to the thing, you start thinking about the dependencies
>and what you have to add to the makefile. None of that with the TDS. On the
>other hand, developing with multiple authors is that much harder, and some
>sensible versioning system would have enhanced the value of the TDS much.

Am I missing the point here, but, there is a utility in the latest version
of the Occam toolset (also in the latest version of the c toolset and if
I remember, is also in the D705 product)---ANYWAY: the utility is called
imakef and builds a makefile (complete with all necessary dependencies).  It
does this by backtracking from the desired .btl/.b8h/etc. to all .occ/.pgm 
files.   Although you do *have* to use standard file extensions so that
imakef can work.  The make program is *not* supplied with the toolset, but
we were able to obtain one from an ftp site.  At this most, most of us here
now rely on this feature - and new user/students come quickly up to speed as
well

Brian d'Auriol

A
     

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
> ...                                                          a collegue
>spent several days of labour (as in GULAG) to produce the makefile. And every
>time you add a file to the thing, you start thinking about the dependencies
>and what you have to add to the makefile. None of that with the TDS. ...

The imakef tool supplied by Inmos with the toolsets does an excelent job in
producing makefiles.  It handles all the dependancies.  If your program has
only one executable and providing you have your #USEs, #INCLUDEs and ISEARCH
variable correct then there's nothing to worry about.  Here at Manchester,
converting a TDS program to toolset has just been a case of using iflat,
renaming one file, a couple of edits, imakef and make.  The recent versions
of imakef even add rules for deletion of intermediate files to save disk
space, and no dependancy checking of ISEARCH files for faster making.
--
Iain Phillips                iwp@cs.man.ac.uk or iwp@uk.ac.man.cs
Dept of Computer Science, University of Manchester, M13 9PL. U.K.

In article <JAN.92Aug12103429@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:

|>    > On a similar note the TDS, like every new and elegant code managing tool;
|>    > once one is fluent with it's workings, has its own continually growing set
|>    > of advantages over traditional editors.
|> 
|>    I think I'll complain about this one too :)
|> 
|>    TDS is not a bad tool; it does have a reasonably good editor and file management
|>    system. My objection is why?. Who needs a new editor?; I mean just how many 
|>    ways can you do a cutandpaste operation!. Personally I like to keep the
|>    option of using any editor I wish (this may ore may not be origami) and I 
|>    like to have more direct control over the files on my disk. As soon as the 
|>    toolset came out, I gladly converted away from the TDS.
|> 
|> Actually, I think the control of disk files is what the TDS does best. When
|> 
|>  Jan Vorbrueggen
|>  jan@neuroinformatik.ruhrunibochum.de



Really??? Admittedly, I use OPS (Meikos' version of TDS) but the number of times that
I've lost files (yes, complete files) due to OPS being unable to update a file (eg due
to the underlying filestore being full) has been really really annoying!!!

And wouldn't it be great to be able to jump to exactly where you wanted in the 24th
nested fold (in one go)!


Now, who wants to inform me a bit more about this toolset....

Michael

In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:
>(3) Is it really elegant to write this:
>
>     IF
>       var1 < 1.0 (REAL32)
>         SEQ
>           var1 := 2.0 (REAL32)
>           var2 := 2.0 (REAL32)
>       TRUE
>         SKIP
>
>     instead of  If( var1 < 1.0 ) Seq{var1 = 2.0;var2 = 2.0;}
>
>Don't get me wrong; Occam has many innovative features; it just seems to
>me that a more sophisticated parser for the syntax would have gone a long
>way towards making it more popular -- and a long way towards keeping
>irritable people like me quieter ;-) .
>     

Ok, but I would ***MUCH*** rather the first syntax for a folding editor.
see below....

     IF
       var1 < 1.0 (REAL32)
         ...  process XYZ
       TRUE
         SKIP

     ...  an if with no idea of *structure*

In general the IF follows the syntax of a tagged protocol.  In both cases,
the following is very easy to read.

     IF
       condition 1
         ...  proc 1
       condition 2
         ...  proc 2
       condition n
         ...  proc n
       guard
         ...  proc guard


In short, I wonder if the extended syntax of Occam (esp. not free formatted)
assists in the coding with a folding editor.
Brian d'Auriol

In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:

>   Elegant tool for expressing parallelism? definitely.
>   Elegant tool for expressing everything else? definitely not.
These two lines sum up OCCAM.


>   (2) I fail to see the advantage of having no operator hierarchy or default 
>       data types:
>
>       why write this:
>
>	  (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32))) - 4.0 (REAL32)
>
>       and count brackets when all I'm trying to do is:
>
>	  1.0 + 2.0*3.0 - 4.0
I think OCCAM is trying to make you aware of exactly what you are
doing numerically, although the use of brackets in the syntax is
confussing.
In ANSI C you also need 1.0f + 2.0f*3.0f - 4.0f to make things clear.
I think a lot of traditional C code ends up with additional type
conversion code produced that the user doesn't see; execpt that it
effect performance. Norcroft's ANSI C is very strong on this with its
'lower precission in wider context' and related warnings.

Thats enougth of me being nice to OCCAM for now. I better stop now
before I think of something to complain about.

--
Michael Stevens, Robotics Research Group,Dept of Engineering Science,Oxford,UK
INTERNET: michael@robots.oxford.ac.uk

   Am I missing the point here, but, there is a utility in the latest version
   of the Occam toolset (also in the latest version of the c toolset and if
   I remember, is also in the D705 product)ANYWAY: the utility is called
   imakef and builds a makefile (complete with all necessary dependencies).  It
   does this by backtracking from the desired .btl/.b8h/etc. to all .occ/.pgm 
   files.   

The slave work is required in spite of imakef trying to give you a first
cut  but that first cut is very rough and needs extensive hand editing,
so when you make any additions/changes, it's not feasable to just run imakef
again. We're talking here of a programme, of course, that has 3 different
programmes, each consisting of a halfdozen processes, all accessing elements
of about a dozen libraries (not counting system libraries). imakef, for
instance, can't figure the libraries out, and how could it, they're arbitrary
anyway.

'nuff said.

While we're at it: Thanks for the official Inmos statement of occam's future.
I especially applaud the development decisions (what to implement first, etc).
Two little questions reamin, however: How optimising do you expect the
compiler to be (e.g. compared with the ACE compilers), and could the delivery
date of 1993 be narrowed a little? Thanks.

 Jan Vorbrueggen
 jan@neuroinformatik.ruhrunibochum.de

In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:

>Elegant tool for expressing parallelism? definitely.
>Elegant tool for expressing everything else? definitely not.

True, but parallelism is not the only thing it is good at expressing.

>The Occam syntax leaves a lot to be desired:

>(1) It is not free formatted; I thought the days of counting columns were over.

Column counting is, the formatting is done elegantly in occam.  One space is not
enough indentation visually, three is too much when one has lots of indenting.

Formatting a program in this way is good as one uses spacial relationships to indicate
the programs structure.  The must be some advantage to the fact that spacial
arrangements are processed by the right hand side of the brain, standard programming
logic by the left.

Formatting a language in this way is also good as one can use it to indicate
information to the compiler, which cuts out the need of lots of end, od, esac, }
and fi keywords.

>(2) I fail to see the advantage of having no operator hierarchy or default 
>    data types:

>    why write this:

>       (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32))) - 4.0 (REAL32)

>    and count brackets when all I'm trying to do is:

>       1.0 + 2.0*3.0 - 4.0

My experience has lead me to do things like this,

  {{{ 1 + 2*3 - 4.0
  ( 1.0(REAL32)  +  (2.0(REAL32) * 3.0(REAL32)))  -  4.0(REAL32)
  }}}

One can add to readability by just adding a spaces (like before the 1) over just
leaving things in the most natural way (like before the 2).
The removing of the space between the zero and the open brackets bonds the
number and the type much better visually thus they read as the one object they are.

By the way, the occam compiler (the one here at any rate) constant folds the above
to 3.0(REAL32).

Occam's approach to typing like this is hard on the fingers and brain sometimes, but
it does make look at what you want the machine to do.  I once realised that although
the obvious way to do something was,

  REAL64 hello, there:
  INT world:
  ((REAL32 ROUND hello) * (REAL32 ROUND there)) + (REAL32 ROUND world)

it was faster to do,

  REAL32 ROUND (hello * there) + (REAL64 ROUND world)

although I think C gets it right in this case, it may not in general and in a
critical loop its nice to have full control.

No the above doesn't answer your point about the advantages, but others have,
here I have decided giving out experience and ideas is more advantageous.

>(3) Is it really elegant to write this:

>     IF
>       var1 < 1.0 (REAL32)
>         SEQ
>           var1 := 2.0 (REAL32)
>           var2 := 2.0 (REAL32)
>       TRUE
>         SKIP

>     instead of  If( var1 < 1.0 ) Seq{var1 = 2.0;var2 = 2.0;}

As others have said, yes.  The occam IF is very elegant in many ways.

Another way to write the above is,

  IF
    var1 < 1.0 (REAL32)
      var1, var2 := 2.0(REAL32), 2.0(REAL32)
    TRUE
      SKIP

Perhaps the multiple assignment isn't more readable, I don't think my personnel taste
prefers it, but its easier to type and were all lazy occasionally.

Jan's comment about wanting

TRUE
  STOP

as the default is a common one.  I wanted it too until I was told why.  I think
it was to catch and stop sloppy programming (not that any of us do that, all of
our programs are bug free aren't they:-).  There might be a case the programmer
has overlooked.

>> On a similar note the TDS, like every new and elegant code managing tool;
>> once one is fluent with it's workings, has its own continually growing set
>> of advantages over traditional editors.
  
>I think I'll complain about this one too :-)

>My objection is why?. Who needs a new editor?; I mean just how many 
>ways can you do a cut-and-paste operation!.

The important issue is that of abstraction.  Making a large thing managable by
humans.  Also as we get more experience at writing editors we get better at
making the c-n-p operations easier to use and more intuitive to the first time
user.

>I like to have more direct control over the files on my disk.

Yes, it needs to be better at actually deleting files.

>Jacob Hirbawi

Warren

Warren> Column counting is, the formatting is done elegantly in occam.  One space is not
Warren> enough indentation visually, three is too much when one has lots of indenting.

In your opinion that is - this smacks too much of Orwellian
overtones to me.  Why not let the programmer choose?

Ok, it provides a standard layout, but open things up and
let people decide over time what they want and they'll come
up with a good working convention (or conventions) for
layout.  I don't like having it enforced arbitrarily from
on-high.

Warren> Formatting a program in this way is good as one uses spacial relationships to indicate
Warren> the programs structure.

Not convinced.  Being forced into a particular layout
doesn't, for me anyway, feel nice.  I'd like to learn what a
good layout style is by getting it wrong, messy, learning
from others etc.  It's a more constructive learning
experience.

Warren> Formatting a language in this way is also good as one can use it to indicate
Warren> information to the compiler

I thought the purpose of abstraction (v.i.) was to make life
easier for the programmer, not for the compiler.  Write in
binary/hex octal if this is what you are worried about.

Warren> , which cuts out the need of lots of end, od, esac, }
Warren> and fi keywords.

But they do make block encapsulation easier to see on the
screen.

Warren> My experience has lead me to do things like this,

Warren>   {{{ 1 + 2*3 - 4.0
Warren>   ( 1.0(REAL32)  +  (2.0(REAL32) * 3.0(REAL32)))  -  4.0(REAL32)
Warren>   }}}

I.e. your comment is syntactic rather than semantic and you
are therefore repeating yourself, when you could have
expressed the equation directly as per the comment in the
first place.

Warren> By the way, the occam compiler (the one here at any
Warren> rate) constant folds the above to 3.0(REAL32).

I suspect (hope?) any decent compiler for any language would
try to do the same in this case.

Warren> Occam's approach to typing like this is hard on the fingers and brain sometimes, but
Warren> it does make look at what you want the machine to do.

I'd rather worry about the problem I am trying to solve than
worry about the machine.

Warren> No the above doesn't answer your point about the advantages, but others have,
Warren> here I have decided giving out experience and ideas is more advantageous.

Warren>   IF
Warren>     var1 < 1.0 (REAL32)
Warren>       var1, var2 := 2.0(REAL32), 2.0(REAL32)
Warren>     TRUE
Warren>       SKIP

Except there is a bug in multiple assignments for the
compiler we have here (TDS2, MEiKO) (or there was last time
I looked at the bug list :-)

Warren> Perhaps the multiple assignment isn't more readable, I don't think my personnel taste
Warren> prefers it, but its easier to type and were all lazy occasionally.

If your personal choice is offended, fine; this is the point
about being able to choose layout etc.  Multiple assignment
can be replaced by a SEQ of assignments; seems to me that
Will's Razor hasn't been used here!

Warren> Jan's comment about wanting

Warren> TRUE
Warren>   STOP

I think you meant SKIP

Warren> as the default is a common one.  I wanted it too until I was told why.  I think
Warren> it was to catch and stop sloppy programming (not that any of us do that, all of
Warren> our programs are bug free aren't they:-).  There might be a case the programmer
Warren> has overlooked.
  
This would seem to indicate the programmer hasn't been
thinking properly about the problem.  A warning from the
compiler would be friendlier.

>My objection is why?. Who needs a new editor?; I mean just how many 
>ways can you do a cut-and-paste operation!.

Warren> The important issue is that of abstraction.  Making a large thing managable by

But above you were worried about getting at the machine to
optimise what you were doing, rather than making life easier
for the programmer.  The current icarnation of the TDS and
occam2 in no way make software management easier (and as you
were talking about "experience", this is an opinion derived
from 7 years' use of occam).  Don't get me wrong, I'm not
stoning occam mercilessly, it's got a few good points, but I
think it needs to go a long way to be "real" (or is that
REAL32? :-)

Warren> humans.  Also as we get more experience at writing editors we get better at
Warren> making the c-n-p operations easier to use and more intuitive to the first time
Warren> user.

The TDS, so far as I can see, does not provide anything that
any other editor can do, and lacks *much* thatcI get it in
others (vi, emacs, etc).  As for folding making life easier,
it is just as easy to abuse the fold structure as it is to
write bulky code in any other editor.  It is also lacking
SCCS type manipulation by using a closed system and a
bizarre file format (binary source files?  I ask you...).

>I like to have more direct control over the files on my disk.
Warren> Yes, it needs to be better at actually deleting files.

This is mainly an artefact of the MEiKO port to handle a
multi-user system (I think).

Just my 2 groats worth...

tony

In <46@pine.ukc.ac.uk> arc1@ukc.ac.uk (tony) writes:


>In your opinion that is - this smacks too much of Orwellian
>overtones to me.  Why not let the programmer choose?
>Ok, it provides a standard layout, but open things up and
>let people decide over time what they want and they'll come
>up with a good working convention (or conventions) for
>layout.  I don't like having it enforced arbitrarily from
>on-high.

Hmm intersting, coz if you extend the 'on_high' argument why arent you
using your own programming language on your own system based on your own
VLSI process.

>Warren> Formatting a program in this way is good as one uses spacial relationships to indicate
>Warren> the programs structure.

>Not convinced.  Being forced into a particular layout
>doesn't, for me anyway, feel nice.  I'd like to learn what a
>good layout style is by getting it wrong, messy, learning
>from others etc.  It's a more constructive learning
>experience.

I agree, but if other people have done the messing about to find the
most natural way why not give it a try? In fact the OCCAM rules correspond to
my own preferred style of programming.

>Warren> , which cuts out the need of lots of end, od, esac, }
>Warren> and fi keywords.
>But they do make block encapsulation easier to see on the
>screen.

I disagree, fortunately or unfortuantely my first real programming experience
was in FORTRAN which has very few block ends etc, and one gets used to
seeing the structure of the code without the brackets, in fact one usually
blocks the code on the screen. When moving onto C etc I found the brackets
annoying, not only to type but because in some cases they are tacked
onto the end of a line or placed seperately, tracking down the end of
a block is hard. OCCAM makes it easier to see. 


-- 
Raggy                 | God smiles upon the little children, the alcoholics, and
u9dmlb@ohm.york.ac.uk | the permanantly stoned. S.King.

In article <1462@eagle.ukc.ac.uk>, wgd@ukc.ac.uk (W.G.Day) writes:
|> In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:
|> 

|> >(2) I fail to see the advantage of having no operator hierarchy or default 
|> >    data types:
|> 
|> >    why write this:
|> 
|> >       (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32))) - 4.0 (REAL32)
|> 
|> >    and count brackets when all I'm trying to do is:
|> 
|> >       1.0 + 2.0*3.0 - 4.0
|> 

Question 1:  Data types

How is a poor compliler supposed to know that that is what you meant? This is
a real, serious question, after all you might have meant

     (1.0 (REAL64) + (2.0 (REAL64) * 3.0 (REAL64))) - 4.0 (REAL64) 

Acctually, this is a poor example, since this expression JUST HAPPENS to give
the same result evaluated single or double precision.  This is not always the
case - try replacing the * with a /.

However, if the expression is seen in context, for example

     REAL32 result :
     SEQ
       result := (1.0 (REAL32) + (2.0 (REAL32) / 3.0 (REAL32))) - 4.0 (REAL32)

then is is arguable that the compiler might reasonably deduce that 1.0
meant 1.0(REAL32); of course, the language would have to state that this was
what happened, AND it would open up a certain risk of programming errors
not being detected, for example, 

        result :=  (1.0 + (2.0 / 3.0)) - 4.0

would be legal, and interpretted as 

        result := (1.0 (REAL32) + (2.0 (REAL32) / 3.0 (REAL32))) - 4.0 (REAL32)

even if the programmer had really meant

        result :=  REAL32((1.0(REAL64) + (2.0(REAL64)/3.0(REAL64))) - 4.0(REAL64))

which signifies a different computation.

Now on balance, **** I ****** (me, that it is, not INMOS) feel that inferring the
data types of literals in these situations would be a good thing, and would
improvge readability - however, the issue is not straightforward.


Question 2: Operator precidence and non-associative operators.

Well, let us suppose that we have inferrence of the data type of literals. Then
our example would be either

              1.0 + 2.0/3.0 - 4.0

or

             (1.0 + (2.0/3.0)) - 4.0

Now, how is the compiler supposed to know that the second example is
what was meant? How indeed? How does it know that you didn't mean 

              1.0 + ((2.0/3.0)) - 4.0)

which is, again, a different computation? (If we were dealing with real numbers 
then (a + (b/c)) - d = a + ((b/c) - d) for non-zero c. However, computers
use only an approximation to the reals, for which the addition operation is
NOT associative).

Again, on balance ,  **** I ****** think that occam ought to obey the
usual operator precidence rules that you learn at school. That would let 
you write

            1.0 + (2.0/3.0 - 4.0) 
or
           (1.0 + 2.0/3.0) - 4.0

depending on what you actually meant. Also, for the genuinely associative 
operators, like BITAND, it ought to let you drop the parenthesisation. However,
the non-quite associatives,  like +, cause me more worry. Again though,
on balance, having written and read numeric programs in occam 2, I would
allow them to be dropped, and for the language to impose a left to right
evaluation rule. Of course, if brakets were used, the compiler would have to obey
them (unlike some other languages I could name). So, the original example
could be written 

            1.0 + 2.0/3.0 - 4.0

and if you really wanted


            1.0 + (2.0/3.0 - 4.0)

that's what you'd write.

As for expressions which mix computer science operations (eg >>) with good
old arithmetic ones (eg +); these should be paraenthesised.

|> Occam's approach to typing like this is hard on the fingers and brain sometimes
|> but it does make look at what you want the machine to do.  I once realised
|> that although the obvious way to do something was,
|> 
|>   REAL64 hello, there:
|>   INT world:
|>   ((REAL32 ROUND hello) * (REAL32 ROUND there)) + (REAL32 ROUND world)
|> 
|> it was faster to do,
|> 
|>   REAL32 ROUND (hello * there) + (REAL64 ROUND world)
|> 
|> although I think C gets it right in this case, it may not in general and in a
|> critical loop its nice to have full control.
|>

These also give different results!

There is some discussion about this subject in  ``The development of occam 2''
in the Transputer Applications Notebook - Architecture and Software.



-- 
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk