🚀 go-pugleaf

In article <rob.721665532@dutncp8> rob@pact.nl (Rob Kurver) writes:
>What's so special about a program running out of memory at runtime?

It stops.  Unfortunately, embedded systems can't prompt the user to add some
more RAM when coming into land.

>How about disk space? How about time?

With disk space the same.  With real time systems one normally thinks
of something sensible to do if you miss a deadline, this could be stopping.

>Having to deal with building your own stack distracts you from the
>real problem at hand, i.e. solving your problem.  Further, the
>extra code required makes your program harder to read and understand,
>especially when you come back in a couple months time.

Yes, I had to build it by hand.  No, I don't find it much harder to
understand today.

>Similarly, having to deal with creating processes, starting processes,
>waiting for processes etc. yourself is distracting and prone to errors.
>It is a job much better done by the compiler.

True, I don't know if the possibilities of constant-at-compile-time
recursion have been looked at.  I suspect they have and that it is 
too expensive in performance terms.

>These language constructs make your program easier to read,  the
>algorithm easier to understand, and thus, ultimately, they help you
>solve your problem quicker.

I hope you mean "express your problem with more brevity".

As we have seen with occam, constructs on their own, are not the most
powerful way to build up a language.  Replication gives occam more
than a for loop could.

In article <MICHAEL.92Nov16185558@lucrece.uk.ac.oxford> michael@uk.ac.oxford.robots (& Stevens) writes:
>FOR recursion:
>	1. Recursion is mathematically elegent. Serious software
>engineering requires it.

I work with a formal method called UNITY (Parallel Program Design, Chandy
and Misra) which comes with a parallel programming notation.  I was
surprised how powerful it is without having recursion in it.

>Ok enough humour, how about the even tricker issue of dynamic memory
>allocation. Does OCCAM 3 need it as part of the language? Should OCCAM
>3 have type safe pointers? Or should we be content with INT32 and
>library procedures to allocate memory?
>
>Would all this overburned OCCAM and turn it into yet another hacked up
>language like C?

Fraid so.

In article <1992Nov17.093335.11067@inmos.co.uk> roger@gimli.inmos.co.uk (Roger Shepherd) writes:
>Actually, a recurive occam-like language is a good idea, and very good fun
>to use.

I would very much like such a language that has all the things that
parallelism prevents: recursion, pointers, dynamic memory and data
structures.  I like having the rigorous semantics and the transformation laws.
Though having said all of that, I also like having PAR without using
PLACED PAR.  It would be interesting to see if occam - PAR + OO is not
as expressive as occam.

The programming language Turing has a formal semantics too, but no structuring
through indenting, replication or the other design decisions I prefer the
direction of in occam.  I think this liking will extend to occam 3 from having
seen Jon Kerridge use of it.

As, no one language can be ideally suited for all applications,
>
>there are a large class of problems which are best handled via a language
>which supports recursion. There are also very many problems which do not.
>
and there appears to be quite an argument along the lines of Michael's "why
don't you have it and just not use it when you don't need it", which as
Roger Shepherd said, means having two compilations approachs (if I understand
correctly).  Perhaps Inmos have a market for a family of occam languages,
occam.par and occam.seq.

Things should not be multiplied beyond need---however, if there's a need.

Warren