home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1237 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  2.1 KB

  1. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!nuug!autro1!teig
  2. From: teig@autro1.UUCP (Oyvind Teig)
  3. Newsgroups: comp.sys.transputer
  4. Subject: occam and recursion and out-of-memory problems
  5. Message-ID: <143@autro1.UUCP>
  6. Date: 23 Nov 92 10:23:27 GMT
  7. Reply-To: teig@autro1.UUCP (Oyvind Teig)
  8. Organization: Autronica A/S, Trondheim, Norway
  9. Lines: 41
  10.  
  11. Recursion of occam-2 or -3
  12.  
  13. Rob Kurver writes as a reply to my post:
  14.  
  15. >>I have seen enough of stack overflow errors to appreciate the lack
  16.                         -------------------->>
  17. >>of recursion in occam.
  18. >
  19. >Recursion + stack-checking -> no stack overflow.
  20. >
  21. >>This comes close to the discussion of exception-handling: how do
  22. >>you solve that in Pact-C, and what would you recommend when stack overflow
  23. >>is encountered?
  24. >
  25. >Upon stack overflow, the stack is extended by allocating a new block of
  26. >memory from the heap.  If this is not possible (out of memory), you get
  27. >a fatal error message and your program aborts.
  28.                                >>---------------
  29. Ok, you have an interesting solution there, of course you do not remove
  30. the out of memory error (which is what I was thinking about).
  31.  
  32. Occam does NOT have out-of-memory errors!
  33. -----------------------------------------
  34. Why couldn't you buy the occam sources from Inmos and add your own
  35. experience and make an occam dialect (that allows recursion etc.) ?
  36. After all - occam has not been standardized.
  37.  
  38. Sure occam isn't C, but C isn't occam either! And you may have adopted
  39. a few of the good things from occam into your C - but you have not made
  40. occam out of it. After all, the security of occam could be
  41. a point to sell?? The lack of pointers, the abbreviations, the retyping,
  42. the othogonality of functions and procedures, the aliasing checks,
  43. the indenting (yes), the protocol with its associated checks, the no-out-
  44. of-memory insurance and least but not last - IT IS MUCH EASIER THAN C.
  45. It is probably too easy for C programmers - who actually would like to
  46. have structured assembler!
  47.  
  48. But YOU could add your own compiler directives to squeeze it a little!
  49.  
  50. 0yvind Teig
  51. Autronica, Trondheim, Norway
  52.