home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1201 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.9 KB  |  109 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: IS Occam3 recursive?
  5. Message-ID: <1992Nov17.093335.11067@inmos.co.uk>
  6. Sender: roger@gimli (Roger Shepherd)
  7. Organization: INMOS Limited, Bristol, UK
  8. References:  <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford>
  9. Date: Tue, 17 Nov 1992 09:33:35 GMT
  10. Lines: 97
  11.  
  12. In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford>, 
  13. michael@uk.ac.oxford.robots (& Stevens) writes:
  14. |> Now the arguments about recursion and OCCAM have been going a while I
  15. |> though I would make a quick summary.
  16. |> 
  17. |> FOR recursion:
  18. |>     1. Recursion is mathematically elegent. Serious software
  19. |> engineering requires it.
  20.  
  21. This depends on what you mean by "serious software enginerring". Certainly,
  22. there are a large class of problems which are best handled via a language
  23. which supports recursion. There are also very many problems which do not.
  24.  
  25. |>     2. Code generation isn't hard. Handle the stack extension is possible.
  26. |> If it can be done for C, you can do it for OCCAM.
  27.  
  28. Errr. C doesn't has concurrency. It is the COMBINATION of concurrency and
  29. recursion which leads to problems. Code generation is possible certainly,
  30. but the resulting code is likely either to waste memory (if you allocate
  31. vast amounts of memory to each process) or will run slowly (dynamic allocation
  32. on every procedure call).
  33.  
  34. |>     3. You don't need to use it. If you want to be able to
  35. |> predetermine memory usage at compile time don't recurese.
  36.  
  37. Unless you provide a system which implements both recursive and non-recursive
  38. occam you will pay the price of supporting recursion even when it is not used.
  39.  
  40. |>     4. Why single out memory as the single resource that should be
  41. |> predetermined at compile time. Time is another resource that runs out,
  42. |> and so does disk space.
  43.  
  44. Running out of memory is just one issue - performance is another. Also, this 
  45. argument strikes me as somewhat specious - "because you can't do everything
  46. correctly, you shouldn't bother doing anything!"+
  47.  
  48. |> Ok enough humour, how about the even tricker issue of dynamic memory
  49. |> allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
  50. |> 3 have type safe pointers? Or should we be content with INT32 and
  51. |> library procedures to allocate memory?
  52.  
  53. Again, there is more to this than the issue of type safe pointers. Remember,
  54. occam is supposed to be a language for programming distributed systems -
  55. this means that pointers may become meaningless when passed from one process
  56. to another.
  57.  
  58. Actually, a recurive occam-like language is a good idea, and very good fun
  59. to use. However, it creates a language which is substantialy different
  60. (in terms of relative costs of operations (+, call, PAR) from occam. In the
  61. past we have built an occam (1?) system which had recursion. It let you
  62. write wonderful (apart from the non-termination of the code) things like:
  63.  
  64.     PROC sieve(CHAN source, sink)
  65.       INT my.prime :
  66.       SEQ
  67.         source ? my.prime
  68.         sink ! my.prime
  69.          
  70.         CHAN to.next.sieve :
  71.         PAR
  72.           sieve(to.next.sieve, sink)
  73.  
  74.           WHILE TRUE
  75.             INT candidate :
  76.             SEQ
  77.               source ? candidate
  78.               IF
  79.                 candidate \ my.prime = 0
  80.                   to.next.sieve ! candidate
  81.                 TRUE
  82.                   SKIP
  83.    :                                          
  84.  
  85.    CHAN to.sieve, from.sieve :
  86.    PAR 
  87.     sieve(to.sieve, from.sieve)
  88.  
  89.     INT candidate :
  90.     SEQ
  91.       n := 2
  92.       WHILE TRUE
  93.         SEQ
  94.           to.sieve ! n
  95.           n := n + 1
  96.         
  97.     
  98.      WHILE TRUE
  99.        INT prime :
  100.        SEQ        
  101.          from.seive ? prime
  102.          print(prime)
  103.     
  104. -- 
  105. Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
  106. 1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
  107. Almondsbury                 INTERNET: roger@inmos.com
  108. +44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
  109.