Re: Larry Wall, on Tcl

On Dec 10, 5:04 pm, Darren New <d...@xxxxxxxxxx> wrote:
Alan Anderson wrote:
Darren New <d...@xxxxxxxxxx> wrote:

Cameron Laird wrote:
EIAS isn't a good thing?
It has its drawbacks. Like, no garbage collection of referenced objects.

What is a "referenced object" and why should I care?

Because garbage collection is good? Especially of external resources
like file handles? If everything is a string, you have no pointers, and
hence no garbage collection.

I write long-running, robust software in Tcl. It would be enhanced by
the ability to use OO features without mistakes leading to leaks, for
example.

I never could figure this out. I always assumed that if I didn't take
care to take out the garbage and also provide a clean slate for new
work, I was introducing potential unexplained behavior. I just fixed a
bug in this category today. I've never heard of an ideal garbage
collection system, so I assume that it is a black art, subject to a
lot of hand waving.

In Tcl, any object (variable, namespace, proc) with a name is a
pointer, if it is ultimately stored in a hash it must be a pointer
with a nice name in a limited scope.

But the idea that something must have a reference count that would
inform the need to garbage collect seems impossible in Tcl. If you
open a file and don't close it, it is still open. A namespace exists
until it is deleted. How do you count references on that?

So the first thing is to define what a non-referenced object would
look like. For many types of referenced objects, the only reasonable
idea (in Tcl) is to have an ownership relationship with a parent
object. When the parent object dies, so must the child objects. And
when parent objects are initialized or reinitialized, things are
cleaned up. This implies a controller above the level of the objects,
and if the controller fails, the entire system must fail and allow the
OS to do cleanup. So GC could be done with a registration process
which triggers on object exit, or you could use a centralized
registration with the controller. On some interval, the controller
will look at the list of registered objects. If the object exists,
nothing is done, otherwise the controller would destroy the child
objects.

I think there is more of a gap between ideal behavior and reality in
this area than in most because you must rely on some parallel or
separate mechanism to enforce cleanup, and require everyone to use the
conventions. And this is the problem. GC requires work, but usually
the offending code is the code which didn't do the work.

.

Relevant Pages

  • Re: Larry Wall, on Tcl
    ... no garbage collection of referenced objects. ... Especially of external resources like file handles? ... It's not feature creep if you put it ...
    (comp.lang.tcl)
  • Re: Larry Wall, on Tcl
    ... no garbage collection of referenced objects. ... What is a "referenced object" and why should I care? ... (I do know the answer to the first question, making it rhetorical, but ...
    (comp.lang.tcl)
  • Re: CLOS object clean-up
    ... > I'm not necessarily referring to garbage collection in the subject. ... and therefore causes the mesh to ragdoll. ... > He asked how this could be done in CLOS since there is no knowledge of ... assuming a one-to-one relationship between mesh and controller, ...
    (comp.lang.lisp)
  • Re: OO in the Tcl core [Was: Re: ITcl 3.3
    ... Garbage collection is the week place of Tcl. ... > subject to explicit releasing. ... >> the C API level. ...
    (comp.lang.tcl)
  • Is garbage collection here yet?
    ... I thought I'd check in on tcl to see if garbage collection (of ... not just strings) was available in the core yet. ... I don't consider tcl to be a fully higher-level language. ...
    (comp.lang.tcl)