How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
stndshp at gmail.com
Tue Aug 17 22:22:09 CEST 2010
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,
> > 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.
More information about the Python-list