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

[Standish P]

On Aug 17, 12:32 pm, John Passaniti <john.passan... at gmail.com> wrote:
> On Aug 17, 2:53 pm, Standish P <stnd... at gmail.com> wrote:
>
> > 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.
>
> A stack is a fine abstraction for some kinds of programming.  It fails
> for others.  In languages where functions are first-class entities
> that can be stored and passed around like any other kind of data,
> stacks can be problematic because a function can out-live the stack
> frame they were created in.
>
> > 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.
>
> No.

you are contradicting an earlier poster from forth who admitted the
part on dicts.

>
> > 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.
>
> That's one view of OOP.  It's not the only one.

and what can you add to enlighten the readers on the other view ?

>
> > 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.
>
> You, like probably everyone else who has thought about how to
> "simplify" languages will eventually end up at the same place-- you'll
> have a model that meets your objectives, but with some programmers
> will find is unnecessarily limiting.  More importantly, you'll run
> into some classes of problems for which your simple model makes things
> inordinately complicated relative to what other languages and
> paradigms offer.

The objective is to discuss those cases via specific examples (not
generalities), and talk ABOUT them, not AROUND them.

> Here's a better idea:  

Its a very fine wild goose chase project statement.

> Become familiar with the languages you've
> cited, and more.  I would recommend Forth, Lisp, Smalltalk or Ruby,
> Lua or JavaScript.  Learn each and then come back and tell us if you
> think limiting the programmer to objects with stack-ordered lifetimes
> is enough.  Oh, and while you're at it, dip your toes into a problem
> domain you don't normally do any work in.  If you're an embedded
> systems guy, then spend some time writing a non-trivial web
> application.  Go outside your comfort zone and find a problem domain
> where cherished idioms and tools no longer apply.  I think it will
> open your eyes.