home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / transput / 938 < prev    next >
Encoding:
Text File  |  1992-08-17  |  4.9 KB  |  147 lines

  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!inmos!inmos.co.uk!gimli!roger
  3. From: roger@gimli.inmos.co.uk (Roger Shepherd)
  4. Subject: Re: occam
  5. Message-ID: <1992Aug17.085900.24218@inmos.co.uk>
  6. Sender: roger@gimli (Roger Shepherd)
  7. Organization: INMOS Limited, Bristol, UK
  8. References: <2490@news.cerf.net> <1462@eagle.ukc.ac.uk>
  9. Date: Mon, 17 Aug 1992 08:59:00 GMT
  10. Lines: 135
  11.  
  12.  
  13.  
  14. In article <1462@eagle.ukc.ac.uk>, wgd@ukc.ac.uk (W.G.Day) writes:
  15. |> In article <2490@news.cerf.net> jcbhrb@nic.cerf.net (Jacob Hirbawi) writes:
  16. |> 
  17.  
  18. |> >(2) I fail to see the advantage of having no operator hierarchy or default 
  19. |> >    data types:
  20. |> 
  21. |> >    why write this:
  22. |> 
  23. |> >       (1.0 (REAL32) + (2.0 (REAL32) * 3.0 (REAL32))) - 4.0 (REAL32)
  24. |> 
  25. |> >    and count brackets when all I'm trying to do is:
  26. |> 
  27. |> >       1.0 + 2.0*3.0 - 4.0
  28. |> 
  29.  
  30. Question 1:  Data types
  31.  
  32. How is a poor compliler supposed to know that that is what you meant? This is
  33. a real, serious question, after all you might have meant
  34.  
  35.      (1.0 (REAL64) + (2.0 (REAL64) * 3.0 (REAL64))) - 4.0 (REAL64) 
  36.  
  37. Acctually, this is a poor example, since this expression JUST HAPPENS to give
  38. the same result evaluated single or double precision.  This is not always the
  39. case - try replacing the * with a /.
  40.  
  41. However, if the expression is seen in context, for example
  42.  
  43.      REAL32 result :
  44.      SEQ
  45.        result := (1.0 (REAL32) + (2.0 (REAL32) / 3.0 (REAL32))) - 4.0 (REAL32)
  46.  
  47. then is is arguable that the compiler might reasonably deduce that 1.0
  48. meant 1.0(REAL32); of course, the language would have to state that this was
  49. what happened, AND it would open up a certain risk of programming errors
  50. not being detected, for example, 
  51.  
  52.         result :=  (1.0 + (2.0 / 3.0)) - 4.0
  53.  
  54. would be legal, and interpretted as 
  55.  
  56.         result := (1.0 (REAL32) + (2.0 (REAL32) / 3.0 (REAL32))) - 4.0 (REAL32)
  57.  
  58. even if the programmer had really meant
  59.  
  60.         result :=  REAL32((1.0(REAL64) + (2.0(REAL64)/3.0(REAL64))) - 4.0(REAL64))
  61.  
  62. which signifies a different computation.
  63.  
  64. Now on balance, **** I ****** (me, that it is, not INMOS) feel that inferring the
  65. data types of literals in these situations would be a good thing, and would
  66. improvge readability - however, the issue is not straightforward.
  67.  
  68.  
  69. Question 2: Operator precidence and non-associative operators.
  70.  
  71. Well, let us suppose that we have inferrence of the data type of literals. Then
  72. our example would be either
  73.  
  74.               1.0 + 2.0/3.0 - 4.0
  75.  
  76. or
  77.  
  78.              (1.0 + (2.0/3.0)) - 4.0
  79.  
  80. Now, how is the compiler supposed to know that the second example is
  81. what was meant? How indeed? How does it know that you didn't mean 
  82.  
  83.               1.0 + ((2.0/3.0)) - 4.0)
  84.  
  85. which is, again, a different computation? (If we were dealing with real numbers 
  86. then (a + (b/c)) - d = a + ((b/c) - d) for non-zero c. However, computers
  87. use only an approximation to the reals, for which the addition operation is
  88. NOT associative).
  89.  
  90. Again, on balance ,  **** I ****** think that occam ought to obey the
  91. usual operator precidence rules that you learn at school. That would let 
  92. you write
  93.  
  94.             1.0 + (2.0/3.0 - 4.0) 
  95. or
  96.            (1.0 + 2.0/3.0) - 4.0
  97.  
  98. depending on what you actually meant. Also, for the genuinely associative 
  99. operators, like BITAND, it ought to let you drop the parenthesisation. However,
  100. the non-quite associatives,  like +, cause me more worry. Again though,
  101. on balance, having written and read numeric programs in occam 2, I would
  102. allow them to be dropped, and for the language to impose a left to right
  103. evaluation rule. Of course, if brakets were used, the compiler would have to obey
  104. them (unlike some other languages I could name). So, the original example
  105. could be written 
  106.  
  107.             1.0 + 2.0/3.0 - 4.0
  108.  
  109. and if you really wanted
  110.  
  111.  
  112.             1.0 + (2.0/3.0 - 4.0)
  113.  
  114. that's what you'd write.
  115.  
  116. As for expressions which mix computer science operations (eg >>) with good
  117. old arithmetic ones (eg +); these should be paraenthesised.
  118.  
  119. |> Occam's approach to typing like this is hard on the fingers and brain sometimes
  120. |> but it does make look at what you want the machine to do.  I once realised
  121. |> that although the obvious way to do something was,
  122. |> 
  123. |>   REAL64 hello, there:
  124. |>   INT world:
  125. |>   ((REAL32 ROUND hello) * (REAL32 ROUND there)) + (REAL32 ROUND world)
  126. |> 
  127. |> it was faster to do,
  128. |> 
  129. |>   REAL32 ROUND (hello * there) + (REAL64 ROUND world)
  130. |> 
  131. |> although I think C gets it right in this case, it may not in general and in a
  132. |> critical loop its nice to have full control.
  133. |>
  134.  
  135. These also give different results!
  136.  
  137. There is some discussion about this subject in  ``The development of occam 2''
  138. in the Transputer Applications Notebook - Architecture and Software.
  139.  
  140.  
  141.  
  142. -- 
  143. Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
  144. 1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
  145. Almondsbury                 INTERNET: roger@inmos.com
  146. +44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
  147.