home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1203 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  4.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!spool.mu.edu!agate!doc.ic.ac.uk!uknet!rook.ukc.ac.uk!eagle.ukc.ac.uk!wgd
  2. From: wgd@ukc.ac.uk (Warren Day)
  3. Newsgroups: comp.sys.transputer
  4. Subject: Re: IS Occam3 recursive?
  5. Message-ID: <2292@eagle.ukc.ac.uk>
  6. Date: 17 Nov 92 17:50:51 GMT
  7. References: <rob.721665532@dutncp8> <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford>
  8. Sender: wgd@ukc.ac.uk
  9. Followup-To: <1992Nov17.093335.11067@inmos.co.uk>
  10. Organization: Computing Lab., The University, Canterbury, Kent.  CT2 7NF, UK.
  11. Lines: 86
  12. Nntp-Posting-Host: eagle.ukc.ac.uk
  13.  
  14. In article <rob.721665532@dutncp8> rob@pact.nl (Rob Kurver) writes:
  15. >What's so special about a program running out of memory at runtime?
  16.  
  17. It stops.  Unfortunately, embedded systems can't prompt the user to add some
  18. more RAM when coming into land.
  19.  
  20. >How about disk space? How about time?
  21.  
  22. With disk space the same.  With real time systems one normally thinks
  23. of something sensible to do if you miss a deadline, this could be stopping.
  24.  
  25. >Having to deal with building your own stack distracts you from the
  26. >real problem at hand, i.e. solving your problem.  Further, the
  27. >extra code required makes your program harder to read and understand,
  28. >especially when you come back in a couple months time.
  29.  
  30. Yes, I had to build it by hand.  No, I don't find it much harder to
  31. understand today.
  32.  
  33. >Similarly, having to deal with creating processes, starting processes,
  34. >waiting for processes etc. yourself is distracting and prone to errors.
  35. >It is a job much better done by the compiler.
  36.  
  37. True, I don't know if the possibilities of constant-at-compile-time
  38. recursion have been looked at.  I suspect they have and that it is 
  39. too expensive in performance terms.
  40.  
  41. >These language constructs make your program easier to read,  the
  42. >algorithm easier to understand, and thus, ultimately, they help you
  43. >solve your problem quicker.
  44.  
  45. I hope you mean "express your problem with more brevity".
  46.  
  47. As we have seen with occam, constructs on their own, are not the most
  48. powerful way to build up a language.  Replication gives occam more
  49. than a for loop could.
  50.  
  51. In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> michael@uk.ac.oxford.robots (& Stevens) writes:
  52. >FOR recursion:
  53. >    1. Recursion is mathematically elegent. Serious software
  54. >engineering requires it.
  55.  
  56. I work with a formal method called UNITY (Parallel Program Design, Chandy
  57. and Misra) which comes with a parallel programming notation.  I was
  58. surprised how powerful it is without having recursion in it.
  59.  
  60. >Ok enough humour, how about the even tricker issue of dynamic memory
  61. >allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
  62. >3 have type safe pointers? Or should we be content with INT32 and
  63. >library procedures to allocate memory?
  64. >
  65. >Would all this overburned OCCAM and turn it into yet another hacked up
  66. >language like C?
  67.  
  68. Fraid so.
  69.  
  70. In article <1992Nov17.093335.11067@inmos.co.uk> roger@gimli.inmos.co.uk (Roger Shepherd) writes:
  71. >Actually, a recurive occam-like language is a good idea, and very good fun
  72. >to use.
  73.  
  74. I would very much like such a language that has all the things that
  75. parallelism prevents: recursion, pointers, dynamic memory and data
  76. structures.  I like having the rigorous semantics and the transformation laws.
  77. Though having said all of that, I also like having PAR without using
  78. PLACED PAR.  It would be interesting to see if occam - PAR + OO is not
  79. as expressive as occam.
  80.  
  81. The programming language Turing has a formal semantics too, but no structuring
  82. through indenting, replication or the other design decisions I prefer the
  83. direction of in occam.  I think this liking will extend to occam 3 from having
  84. seen Jon Kerridge use of it.
  85.  
  86. As, no one language can be ideally suited for all applications,
  87. >
  88. >there are a large class of problems which are best handled via a language
  89. >which supports recursion. There are also very many problems which do not.
  90. >
  91. and there appears to be quite an argument along the lines of Michael's "why
  92. don't you have it and just not use it when you don't need it", which as
  93. Roger Shepherd said, means having two compilations approachs (if I understand
  94. correctly).  Perhaps Inmos have a market for a family of occam languages,
  95. occam.par and occam.seq.
  96.  
  97. Things should not be multiplied beyond need---however, if there's a need.
  98.  
  99. Warren
  100.