Re: Is garbage collection here yet?

As the OP, let me clarify where I was coming from in starting this
thread. I know that the following is a gross simplification, but I'd
like to try to give a hint of how tcl appears to one programmer who
frequently writes in other high-level languages.

Virtually every modern, high-level, scripting language, such as perl,
ruby, or python, has some form of GC. Many modern, non-scripting
languages such as java also have GC. Even older languages such as lisp
and smalltalk have GC. One broad GC classification divides these
languages by the style of GC: either reference-counting or mark-sweep
and its variants. Reference counting has the benefit of immediately
"finalizing" unreachable referents, but it has some drawbacks, too.

All these languages have some form of anonymous references, where a
data structure can be referred to without being named. Sometimes these
references are implicit, other times they're explicit, but one thing is
for sure: they're darn handy. With them, you can easily build
multilevel, nested data structures very easily. Sometimes the data
structure can be thought of as an "object" of some sort. Other times,
it's just a record or an array or hashtable. These anonymous
references are managed by GC because it's very hard to accurately keep
track of them by hand.

Tcl seems to have avoided adding something resembling references to the
language, but IMHO this causes programmers to jump through unnatural
hoops to simulate them with other means, e.g. naming every object and
storing the name in some hashtable somewhere. And because objects end
up with "names" as their "references", it's hard to implement GC
because its impossible to know when an object is really dead.
Consequently, whenever someone implements a tcl object system, they end
up forcing the caller to track all his objects and destroy them
explicitly or use other tricks (such as tracing?) to get the objects'
memory reclaimed.

Part of the "problem" seems to be that tcl wants everything to be a
string or at least reconstructable from a string. This causes issues
which other languages have solved by negating the premise: references
cannot be reconstituted from a string.

For me, the bottom line is that, although tcl has many, very elegant,
clean abstractions, such as vfs, that lend themselves to simple,
streamlined solutions to various problems, it appears (to me) that when
it comes to building multi-level nested data structures, the techniques
available are all less than elegant or streamlined. In particular,
objects or nested data structures shouldn't have to be explicitly
destroyed and a procedure should be able to return an object or nested
data structure to its caller without naming every piece of it.

I know that many smaller programs do not need GC or references, but
it's hard for me to imagine writing a larger program without
references. Certainly GC (of data structures, not just strings) is
preferable for larger programs. And even smaller programs would gain
in clarity and expressiveness if data structures didn't have to be
named, tracked and destroyed.

I hope this clarifies the reason why I wrote the original post and what
I was hoping for. BTW, my primary experience with tcl is through a
medium size client-server tcl application and GUI I wrote which has
been used heavily on a daily basis for about 7 years now.

-- John Wiersba

.

Relevant Pages

  • Re: I want to know the pros and cons of TCL....
    ... implement it using references and/or copying under the hood. ... languages don't expose how they manage memory on the program's behalf. ... I guess the main difference is that in Tcl you can't specify what you ... the:: namespace), procedure definitions, namespaces and their ...
    (comp.lang.tcl)
  • Re: reusing "code entities" without oop
    ... oop for in other languages are achievable in a non oop way in tcl.> ... Not knowing the specific references in question, ... pure tcl" approach, or if they are thinking of using namespaces, the ...
    (comp.lang.tcl)
  • Re: How come Ada isnt more popular?
    ... then But non contigous representation of arrays will really stress ... It's easy with value-oriented languages (i.e. languages ... use references because of that. ... The example you mentioned was a tree. ...
    (comp.lang.ada)
  • Re: OT:C/C++ Opinion Poll
    ... structure that has a longer lifespan than the object it references). ... major data structures so that they are easily accessible. ... You can do the same with explicit memory management. ...
    (comp.arch.embedded)
  • Re: How come Ada isnt more popular?
    ... The language does not require array implementation to be contiguous. ... then But non contigous representation of arrays will really stress ... It's easy with value-oriented languages (i.e. languages ... use references because of that. ...
    (comp.lang.ada)