🚀 go-pugleaf

In <143@autro1.UUCP> teig@autro1.UUCP (Oyvind Teig) writes:

>>Upon stack overflow, the stack is extended by allocating a new block of
>>memory from the heap.  If this is not possible (out of memory), you get
>>a fatal error message and your program aborts.
>                               >>---------------
>Ok, you have an interesting solution there, of course you do not remove
>the out of memory error (which is what I was thinking about).

Correct.  The out of memory problem can only be solved by not running
out of memory.  So either the development system should not support
any dynamic memory (a rather Orwellian approach), or the user should
be careful about using dynamic memory.  If the development system
supports dynamic memory, he can still _choose_ not to use it if he
thinks that's a good idea!!

>Occam does NOT have out-of-memory errors!

Occam does not have dynamic memory support, so can not run out of
memory at run-time.  It is still possible, though, to fake dynamic
memory - and apparently there are quite a few people who feel the
need to do this (perhaps just because they don't want to go back to
the days of `fatal error - xxx table overflow' messages).  When
dynamic memory is faked, the program can have out of memory errors.
Similarly, if the development system supports dynamic memory but
the program doesn't use it, the program will not suffer from out
of memory errors.

It's not the language feature but the programming construct that
determines whether out of memory errors may occur or not.  Apparently,
dynamic memory is useful in quite a few situations.  In these
situations, having to build your own dynamic memory support does
not improve security.

>Sure occam isn't C, but C isn't occam either! And you may have adopted
>a few of the good things from occam into your C - but you have not made
>occam out of it.

No, we have not made occam out of it, nor did we want to.  Many people
_like_ recursion, pointers, data structures, etc.  They like being able
to take their existing code and run it on the transputer unchanged.
PACT Parallel C is definitely not occam!

>                 After all, the security of occam could be
>a point to sell?? The lack of pointers, the abbreviations, the retyping,
>the othogonality of functions and procedures, the aliasing checks,
>the indenting (yes), the protocol with its associated checks, the no-out-
>of-memory insurance

Yes, the security of occam is useful in some situations.  But because
some of the security is provided by the rather Orwellian approach of
removing features, the language ends up less secure when people find
themselves forced to hack around the language barriers and revert to
assembly, explicit stacks, etc.

>                    and least but not last - IT IS MUCH EASIER THAN C.
>It is probably too easy for C programmers - who actually would like to
>have structured assembler!

I don't find Occam easier than C.  I know C, I like C and I like
being able to write powerful and concise code (with all those bad
things like recursion, pointers, data structures, etc.).  It may well
be that you find Occam easier, but please don't tell me that I should
as well.

As for assembler, I thought Occam was the assembly language of the
transputer? :-)

>0yvind Teig
>Autronica, Trondheim, Norway
--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032