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

[Standish P]

On Aug 17, 1:19 pm, Standish P <stnd... at gmail.com> wrote:
> 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

program a universe simulator using a turing machine.