home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1243 < prev    next >
Encoding:
Text File  |  1992-11-23  |  3.8 KB  |  88 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!mcsun!sun4nl!dutrun!dutrun2!dutncp8!rob
  3. From: rob@pact.nl (Rob Kurver)
  4. Subject: Re: occam and recursion and out-of-memory problems
  5. Message-ID: <rob.722532404@dutncp8>
  6. Sender: news@dutrun2.tudelft.nl (UseNet News System)
  7. Nntp-Posting-Host: dutncp8.tn.tudelft.nl
  8. Organization: PACT, Delft, The Netherlands
  9. References: <143@autro1.UUCP>
  10. Date: Mon, 23 Nov 1992 15:26:44 GMT
  11. Lines: 75
  12.  
  13. In <143@autro1.UUCP> teig@autro1.UUCP (Oyvind Teig) writes:
  14.  
  15. >>Upon stack overflow, the stack is extended by allocating a new block of
  16. >>memory from the heap.  If this is not possible (out of memory), you get
  17. >>a fatal error message and your program aborts.
  18. >                               >>---------------
  19. >Ok, you have an interesting solution there, of course you do not remove
  20. >the out of memory error (which is what I was thinking about).
  21.  
  22. Correct.  The out of memory problem can only be solved by not running
  23. out of memory.  So either the development system should not support
  24. any dynamic memory (a rather Orwellian approach), or the user should
  25. be careful about using dynamic memory.  If the development system
  26. supports dynamic memory, he can still _choose_ not to use it if he
  27. thinks that's a good idea!!
  28.  
  29. >Occam does NOT have out-of-memory errors!
  30.  
  31. Occam does not have dynamic memory support, so can not run out of
  32. memory at run-time.  It is still possible, though, to fake dynamic
  33. memory - and apparently there are quite a few people who feel the
  34. need to do this (perhaps just because they don't want to go back to
  35. the days of `fatal error - xxx table overflow' messages).  When
  36. dynamic memory is faked, the program can have out of memory errors.
  37. Similarly, if the development system supports dynamic memory but
  38. the program doesn't use it, the program will not suffer from out
  39. of memory errors.
  40.  
  41. It's not the language feature but the programming construct that
  42. determines whether out of memory errors may occur or not.  Apparently,
  43. dynamic memory is useful in quite a few situations.  In these
  44. situations, having to build your own dynamic memory support does
  45. not improve security.
  46.  
  47. >Sure occam isn't C, but C isn't occam either! And you may have adopted
  48. >a few of the good things from occam into your C - but you have not made
  49. >occam out of it.
  50.  
  51. No, we have not made occam out of it, nor did we want to.  Many people
  52. _like_ recursion, pointers, data structures, etc.  They like being able
  53. to take their existing code and run it on the transputer unchanged.
  54. PACT Parallel C is definitely not occam!
  55.  
  56. >                 After all, the security of occam could be
  57. >a point to sell?? The lack of pointers, the abbreviations, the retyping,
  58. >the othogonality of functions and procedures, the aliasing checks,
  59. >the indenting (yes), the protocol with its associated checks, the no-out-
  60. >of-memory insurance
  61.  
  62. Yes, the security of occam is useful in some situations.  But because
  63. some of the security is provided by the rather Orwellian approach of
  64. removing features, the language ends up less secure when people find
  65. themselves forced to hack around the language barriers and revert to
  66. assembly, explicit stacks, etc.
  67.  
  68. >                    and least but not last - IT IS MUCH EASIER THAN C.
  69. >It is probably too easy for C programmers - who actually would like to
  70. >have structured assembler!
  71.  
  72. I don't find Occam easier than C.  I know C, I like C and I like
  73. being able to write powerful and concise code (with all those bad
  74. things like recursion, pointers, data structures, etc.).  It may well
  75. be that you find Occam easier, but please don't tell me that I should
  76. as well.
  77.  
  78. As for assembler, I thought Occam was the assembly language of the
  79. transputer? :-)
  80.  
  81. >0yvind Teig
  82. >Autronica, Trondheim, Norway
  83. --
  84.      PACT                   Rob Kurver
  85.     Foulkeslaan 87         rob@pact.nl
  86.    2625 RB Delft     ph: +31 15 616864 
  87.   The Netherlands   fax: +31 15 610032
  88.