[clean-list] Memory usage in recursion

[Richard A. O'Keefe]

	R.A.K. quotes:
I think that was supposed to be R.A.O'K or even R.O'K.
	
	> >Is this also the case in Clean or is the data storage during 
	> >recursion handled in a different way?
	
	> You don't need to know.  There isn't any special problem.
	
	
	Weeelll, <<cum grano salis>>...
	
	We have also the laziness.

Indeed.  There isn't any _special_ problem with data on the stack in Clean
because it is really very difficult to tell what data will be where when.
	
	About EZ phrase: "usually (if not always)..."
	Not always. (And not only because the compilers of, say, C++ are lousy).
	In Prolog or other Logic Programming Languages the calls often must
	leave something on the "trail" in order to enable the backtracking.
	So, even the tail calls may overflow internal data structures, unless
	the user is conscious and "cuts" the backtrack points.
	
In Prolog, there are separate notions of
 - code area
 - heap
 - trail
 - choice point stack
 - environment stack
In a well engineered Prolog system, the only way any one of these areas can
overflow is because the total overflows available virtual memory.
You should cut choice points precisely when the logic of your application
says that those choices are not relevant, not as a space saving measure.
Backtracking is to Prolog what laziness is to functional languages.
Both of them make the use of space, and even the cost of programs, very
VERY hard for beginners and even moderately experienced programmers to
predict, and both of them make it hugely unreasonable to expect programmers
to set the sizes of individual memory partitions.

One key point in all of this is that there is no reason to believe that
there is such a thing as "the" stack, or for "the" stack if there is one
to live in the same region of memory as the C stack (if it has one), so
limitations like the old DOS stack segment limit are not necessarily
relevant to languages other than C.