How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[Standish P]

On Aug 16, 12:20 am, Standish P <stnd... at gmail.com> wrote:
> [Q] How far can stack [LIFO] solve do automatic garbage collection and
> prevent memory leak ?

> Because a stack has push and pop, it is able to release and allocate
> memory. We envisage an exogenous stack which has malloc() associated
> with a push and free() associated with a pop.

> The algorithm using the stack would have to be "perfect" to prevent
> stack overflow or condition of infinite recursion depth. This would
> involve data type checking to filter out invalid input. The task must
> be casted in an algorithm that uses the stack. Then the algorithm must
> be shown to be heuristically or by its metaphor, to be correct using
> informal reasoning.

> Are there any standard textbooks or papers that show stacks
> implemented in C/C++/Python/Forth with malloc/free in push and pop ?
> If Forth is a general processing language based on stack, is it
> possible to convert any and all algorithms to stack based ones and
> thus avoid memory leaks since a pop automatically releases memory when
> free is an intrinsic part of it.

> K&R ANSI has the example of modular programming showing how to
> implement a stack but he uses a fixed length array. It is also
> possibly an endogenous stack. We look for an exogenous stack so that
> element size can vary.
>
> =======
> Standish P <stnd... at gmail.com>

Another way to pose my question, as occurred to me presently is to ask
if a stack is a good abstraction for programming ? Certainly, it is
the main abstraction in Forth and Postscript and implementable readily
in C,C++ and I assume python.

It is true that the other languages such as F/PS also have borrowed
lists from lisp in the name of nested-dictionaries and mathematica
calls them nested-tables as its fundamental data structure.

I am asking for a characterization of algorithms that benefit from
this abstraction or programming paradigm and comparison with others.

The whole case of OOP is the clustering of thought, ie book-keeping,
in the mind of the programmer around fewer objects than ten or twenty
fold functions.

so the name of the game is the same, ie to help the programmer keep
track of things for writing fault free code without chasing every
case, easy visualization, easy recall and communication with fellow
programmers of abstract concepts in terms of real world objects and
easy modification and code reuse.