Darren New <dnew@san.rr.com> 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? (I do know the answer to the first question, making it rhetorical, but the second question is legitimate.)

Darren New <dnew@san.rr.com> wrote: > > What is a "referenced object" and why should I care? > > Because garbage collection is good? Especially of external resources > like file handles? Garbage collection is good, but it requires knowing that something is garbage. If I'm writing a program, I figure that *I* know best when something can be thrown away. > If everything is a string, you have no pointers, and > hence no garbage collection. You have no *automatic* garbage collection service in Tcl, but you can still unset variables and close files and generally delete unnecessary stuff yourself if you want to. > 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 don't follow you. How does a reference-counting garbage collection system help you avoid making such mistakes? It seems to me that leaving garbage collection up to "the system" makes it *easier* to accidentally leave something in an unused but still-present state, because you don't get in the habit of cleaning up after yourself.

Darren New wrote: > RHS wrote: >> Reference Counting has benefits and limitations, but it's certainly >> not broken. > > "Broken" in the sense that it can't collect circular references. Got a > doubly-linked list? Better not try to reference count it. Knuth's TAOCP has a reference to a paper that includes a solution for handling circular references with reference-counted GC. George

Darren New <dnew@san.rr.com> wrote: > If six pieces of your > program need to use a resource, but you need to clean it up when all of > them are done with it, how do you do that in a way you don't need to > change any of those six when you add a seventh program portion using > that same resource? Is this a trick question? The problem is weakly specified, but the obvious answer is to use a semaphore to keep track of the resource usage, and to clean it up when the semaphore shows that it has become unused.

Darren New <dnew@san.rr.com> wrote: > Alan Anderson wrote: > > Is this a trick question? The problem is weakly specified, but the > > obvious answer is to use a semaphore to keep track of the resource > > usage, and to clean it up when the semaphore shows that it has become > > unused. > > Well, yeah. How do you think garbage collection works? Are you saying > "Duh, it's possible to implement garbage-collection techniques manually > every time you need it?" Sure. Welcome to turing completeness. My philosophy is this: I'm the one writing the program, so I'm the one who knows best when it's appropriate to clean things up. I know which "garbage-collection technique" is most appropriate for the specific issue I'm facing. I don't like the indeterminacy that goes along with "automatic" garbage collection. Since my formative years were spent programming what are now called "embedded systems", I have a strong urge to be as spartan as possible and to clean up after myself. A garbage collection system that tries to clean things up for me is almost always less efficient than something I can implement easily and explicitly, and is sometimes a source of subtly inconsistent behavior.

EKB <eric@kb-creative.net> wrote: > I've just got to point out that he's not saying it's impossible to > write robust C programs, just that it leaves a lot more work for the > programmer. I guess I don't understand the mindset that makes behind-the-scenes garbage collection a priority. So far as I'm concerned, it *is* the job of the programmer to make the programs work. I probably don't create the kind of programs that could benefit from having the system do such things for me, because I don't really know what I would do differently if there were a garbage collection service running. I just don't see it making any less work for me.

Darren New <dnew@san.rr.com> wrote: > tom.rmadilo wrote: > > I wish someone would explain why the need to GC could be considered a > > good thing if you use a language that strictly speaking cannot create > > garbage. > > Your view of "garbage" is too limited. In the context of "garbage collection", isn't the view rather well defined? I wonder what yours is. My view is that it's a resource which can be used and later returned to availability, but has somehow been misplaced before being returned. Nothing is actively using it, or *can* actively use it, because the way to use it has been lost. I suppose one can intentionally create something like garbage in Tcl by discarding the result of a command like [open] or [image create] (though it's probably still theoretically possible to recover such handles with suitable introspection). But that strikes me as a contrived example.

"tom.rmadilo" <tom.rmadilo@gmail.com> wrote: > This is real nonsense. > 1. tclsh either is or isn't an application, your choice. > 2. some loadable module is or isn't an application, your choice. > 3. combine the two so you can use the loadable module or extension, > and only that extension. Is that an application or not? I think the terminology confusion here arises from your giving things like Jacl and TCOM the label "Tcl application". I'd have expected that to mean an application written in Tcl. I can see where it might be appropriate to use it to refer to a program like wish, but that would be using "Tcl" to name what the program *is* rather than what it is written in.

Darren New <dnew@san.rr.com> wrote: > To claim that discarding the result of [open] before a corresponding > [close] doesn't create garbage because you can get to it with [file > channels] misses the whole point. Would you mind stating the point explicitly for me? My guesses all seem to be missing the mark, and I'd rather have something concrete to address. > Sure, you can get to it with [file > channels], but you can't know whether other parts of the application are > still using that handle or not. I'm starting to feel like I'm in a foreign city and I don't recognize the street signs. I read your words, and they form understandable sentences, but they don't seem to address anything I would consider a real problem. If you're the programmer and you don't know whether the application is done using a file, ask the application. If the application doesn't know whether it's done using a file, that's a bug. In my view, such an application is broken and needs to be fixed. I don't understand how fixing it properly can be done by invoking a garbage collection system. Obviously I don't see the need for automatic garbage collection. I'd honestly appreciate an example where it is necessary, or even where it solves a problem that isn't easy to prevent in the first place.

Oscar Fuentes <ofv@wanadoo.es> wrote: > A GC system just manages > memory. This relieves the programmer of one nasty task, namely, > releasing data objects that are no longer needed. If that's what GC means, then Tcl already has it. Every "data object" in Tcl is a string. As soon as a variable goes out of scope, or if a variable's value is modified to require a different amount of memory, the Tcl interpreter releases the memory originally used. The garbage collection is immediate, perfect, and unassailable. But if that's all GC means, it seems rather a trivial thing to get all worked up over. The label "garbage collection" to me implies something a lot more involved than simply reclaiming the memory used by unneeded data. I thought the whole point of GC was to determine *when* data objects are no longer needed, so that they can be released without explicit action by the programmer. > Another major advantage of GC is that it makes natural certain > programming practices, such as Functional Programming, with its > closures, functors, etc. and attaching data context to code in > general. This is a very important "feature" of GC. I'll admit to being mostly ignorant on the fine points of FP. My partially informed impression is that data is temporary, and doesn't stick around when it's not needed. I'd imagine GC in such a case is also immediate, and thus barely qualifies as GC the way I thought of it.

Mark Janssen <mpc.janssen@gmail.com> wrote: > Of course creating the memory leak in the > first place is a programming bug, but that's not the point. Does GC mask such bugs? If so, I'd call it a very bad solution. Bugs should not be swept under the rug. They should be exposed, exposed quickly, and exposed with the least possible politeness. :) > The point > of GC is that you don't have to do the bookkeeping anymore allowing > you to focus on more pressing tasks like actually creating a > functional application. I don't understand how I need to do any less bookkeeping. If I don't keep track of when I'm finished with a resource, how am I to trust that the system isn't going to "garbage collect" it out from under me before I'm ready? How am I to trust that the system *is* going to collect it when I'm through? If the system is to know accurately whether or not the resource is still in use, there's got to be something specific I'm doing when I'm done with it. I'd be doing that thing whether or not I'm taking responsibility for freeing it myself. So why is it any less work on my part to keep track of it? It still feels very, very strange to me. I don't use a lot of dynamic memory allocation in C -- my low-level programming is generally targeting PIC processors in specialized embedded applications -- but it just seems wrong to take a chunk of memory and not give it back explicitly when I'm done with it.

I don't want to be contentious. I'm not arguing merely for the sake of arguing. I honestly want to understand what's so great about garbage collection, and what it does to make things easier for me as a programmer. So far, I have seen examples that are obviously invented to showcase the kind of programming errors that GC can clean up after, and I've seen analogies that fail to address the question of what makes it any easier to rely on GC. Darren New <dnew@san.rr.com> wrote: > Alan Anderson wrote: > > Mark Janssen <mpc.janssen@gmail.com> wrote: > > > >> Of course creating the memory leak in the > >> first place is a programming bug, but that's not the point. > > > > Does GC mask such bugs? > > No. It stops it from being a bug. Does virtual memory mask allocating > too much address space? Is this another trick question? Yes, virtual memory *does* mask the bug of a program allocating too much. It keeps the bug from being noticed unless the subsystem using slow physical memory to back the virtual memory is overwhelmed. Everything seems to work fine up to a point, and then suddenly one encounters unexpected and seemingly unpredictable delays, perhaps leading eventually to thrashing and unacceptably slow performance of the entire system. > >> The point > >> of GC is that you don't have to do the bookkeeping anymore allowing > >> you to focus on more pressing tasks like actually creating a > >> functional application. > > > > I don't understand how I need to do any less bookkeeping. If I don't > > keep track of when I'm finished with a resource, how am I to trust that > > the system isn't going to "garbage collect" it out from under me before > > I'm ready? > > Because that's how garbage collectors work. You trust it for the same > reason you trust that a file's space won't get reused until you delete it. Note: the file's space won't get reused until *I* delete it. There's an explicit action on my part that separates "in use" from "not in use". > > How am I to trust that the system *is* going to collect it > > when I'm through? > > Because that's how garbage collectors work. You trust it for the same > reason you trust that a file's space *will* get reused *after* you > delete it. Note: the file's space will get reused after *I* delete it. There's an explicit action on my part that separates "in use" from "not in use". None of this helps me understand how a garbage collector can know for certain that my program is done with something _unless I say so_. So far as I can tell, I'm still tasked with the "bookkeeping" of when I'm using it and when I'm not. I still have to say "done using this chunk of memory" at some point, don't I? I can't see that freeing the memory myself at that point gives me any more to keep track of. > > If the system is to know accurately whether or not > > the resource is still in use, there's got to be something specific I'm > > doing when I'm done with it. > > Nope. That's the point. > > { char * x = malloc(10000); exit(0); } > > What did you have to do with the malloc'ed space to return it to the > system? Does it change depending on how much space you malloc'ed? This is another trick question, right? This example explicitly returns control of *everything* to the system by calling exit(). Hiding it on the same line as the malloc() doesn't make it go away. And it looks like a completely useless example for trying to get me to understand how garbage collection helps me as a programmer, because the program itself is now gone and can't reuse any of that memory anyway. > > just seems wrong to take a chunk of memory and not give it back > > explicitly when I'm done with it. > > It's what you're used to. What do you do to explicitly free up registers > in your C code when you're done with them? How does your code know when > it's OK to reuse AX, and that you don't have something you need in there > you'll use 10 instructions later? You're talking about things that don't exist in my universe. My C code doesn't use registers, and I suspect neither does yours. The compiled machine instructions to implement that code on a specific target CPU will perhaps use the AX register, but C code cares nothing about such details. (Actually, most of the C code I write is incapable of *knowing* when a register is available for reuse, because it's targeted for a CPU that doesn't have registers in the traditional sense.)

Darren New <dnew@san.rr.com> wrote: > Alan Anderson wrote: > > If that's what GC means, then Tcl already has it. Every "data object" > > in Tcl is a string. > > Except for the data objects that aren't strings. That's kind of what the > discussion is about. Please give me an example. I'd prefer one that doesn't involve extensions written in something other than Tcl, since I figure those would be outside the scope of any potential Tcl garbage collection system. I've been trying to identify a problem with using Tcl that garbage collection could help solve. So far, I've seen nothing to help me in that goal. The assurances and explanations of its general goodness all seem to assume that I already know that GC is a good idea, and that I already know how to use it effectively.

Darren New <dnew@san.rr.com> wrote: > The problem is that in small systems, resources are easy to keep track > of. In large systems, they're not, due to multiple layers of abstraction > between where items are allocated and where they're used. If an item gets created at a different level from where it's used, I'd call that a bad design. I would prefer to fix the design so resource tracking remains easy, and I would resist patching the design to give a "wizard" special powers to go around recycling data that the program has lost track of. > How easy would C be if every call to "free" had to indicate what line of > source code the corresponding "malloc" was on? Sure, if each chunk of > memory allocated was only freed in one place, it wouldn't be too > painful. But get a library where the person writing the library wants to > change the code to allocate things in multiple places to deal with new > resources, which perhaps the application programmer isn't even dealing > with, and suddenly it gets really messy. Such messiness again sounds like the result of a bad design. It seems as if it would be easier to enforce an "allocate once, free once" requirement. > > Yes, virtual memory *does* mask the bug of a program allocating too > > much. It keeps the bug from being noticed unless the subsystem using > > slow physical memory to back the virtual memory is overwhelmed. > > Unless that never happens. In which case the bug is masked effectively. It is, however, still present. > > Note: the file's space won't get reused until *I* delete it. There's an > > explicit action on my part that separates "in use" from "not in use". > > As there is in a GC system. When you make the data no longer accessible > within the semantics of the language you're using, it can be collected. > For example, when you overwrite the last pointer to the block of memory, > it can be freed automatically. Are you saying I do have to tell the system I'm finished, or are you saying I don't? You call it an explicit action, which assumes the former, but your example talks about an implicit action. > > None of this helps me understand how a garbage collector can know for > > certain that my program is done with something _unless I say so_. > > If you have a chunk of memory to which no pointer points, it's garbage. > For this to work, you have to be working at a level above that of the > raw bytes of the machine language. > [...] > When you overwrite the last pointer, the memory is freed. This all sounds dangerously unpredictable to me. I can see I will have to do some real reading on the topic of garbage collection in order to get a useful handle on it. > In the Tcl world, when there's no longer any string anywhere in the > program that contains "file5", then the fifth file handle gets closed. So > > set x [open /tmp/one] > set y [open /tmp/two] > set x $y > would close /tmp/one on the third line. This is describing a hypothetical "if Tcl had garbage collection on open files" situation, right? It certainly doesn't correspond to my expectations for an existing Tcl program. > [...] > Ding ding ding! That's the point. You don't need to worry about when > your registers are free, any more than with GC you worry about when your > memory is free. It's an entirely different level of abstraction. How is working with memory a different level of abstraction? C pointers *do* point to memory. It's part of the language, not part of the compiler's implementation and/or optimization. > You > don't tell the GC the memory is free, any more than you tell the C code > that the register is free. You never see the GC in operation, as such. > If you do, you're doing the same level of optimizations that using the > "register" keyword implies. This doesn't make sense to me. C code doesn't *have* registers, but it does have memory allocation. I don't see the two situations as at all similar. But I won't pursue it here any longer. Thank you for your attempts to enlighten me, and I hope you enjoy and appreciate the non-garbage-collected Tcl we have today. We now return to the comp.lang.tcl newsgroup, already in progress.

"davidnwelton@gmail.com" <davidnwelton@gmail.com> wrote: > > It still feels very, very strange to me. I don't use a lot of dynamic > > memory allocation in C -- my low-level programming is generally > > targeting PIC processors in specialized embedded applications -- but it > > just seems wrong to take a chunk of memory and not give it back > > explicitly when I'm done with it. > > In Tcl, do you call 'unset' when you're done with variables? I see your point. No, I generally let the variable evaporate on its own when it goes out of scope. I do explicitly close open files, and destroy unneeded images, and things like that. But I rely on the proc to clean up after itself without even thinking about it. So I don't explicitly remove a variable from existence. I don't think this makes me a hypocrite, because I didn't explicitly bring it into existence either. :)

Darren New <dnew@san.rr.com> wrote: > My only involvement was pointing out that GC of anything other > than strings is difficult in a language where EIAS. I don't think there's a reasonable response to this. If everything is a string, then there's nothing besides strings to collect. GC of anything other than strings is *impossible* in such a language.

Darren New <dnew@san.rr.com> wrote: > You can't identify garbage in Tcl. Oh? That neatly explains my continued frustration and confusion on the topic. I've been trying to interpret things in the context of Tcl. This *is* the comp.lang.tcl newsgroup, after all, and I even checked to make sure the discussion wasn't cross-posted to some other language's forum. Now that I know the idea of garbage collection is irrelevant here, I can stop being so confused and start expanding my context.