Orchid XP v7 <voi### [at] devnull> wrote:
> Garbage collection.

> In Haskell, a "string" is a linked-list of characters.

  I shudder thinking how much memory that must require...

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Data is automatically destroyed as it goes out of scope.

  But in this case the data is one big string?

  Someone else said that string are actually linked lists of characters
where each character is garbage-collected. This must require humongous
amounts of memory, especially considering that one character would only
require 1 byte...

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Letting go of a 
> pointer to a file handle causes the file to be closed WHEN THE GC RUNS, 
> however exhausting the OS handles limit does not trigger the GC...

  This is exactly one of my points in my "I hate Java" page. Garbage
collection is good when the resource is memory, but memory is not the
only resource you can allocate. In some cases (as this one) you have
to free the resource *immediately* when it's not needed anymore, else
malfunction can happen.

  Of course in good modular programming it's the same module which
reserved the resource which should take care of freeing it when it's
not needed anymore. Having to manually call some cleanup function from
the outside breaks modularity.

  What I wonder is why everyone talks like there wouldn't be any negative
sides to GC.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Simply let lazy evaluation read the file as required, and the GC can 
> delete the data you've already processed transparently behind you.

  That's not possible if the file is indeed read into one single string.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   What I wonder is why everyone talks like there wouldn't be any negative
> sides to GC.

Here's the thing: If you could find all the root pointers in a C++ 
program and know which things pointed to what, you could add GC to C++ 
pretty easily without losing any functionality. GC is a strict superset 
of what C++ gives you, avoiding much of the copying and most or all of 
the errors that C++ leaves you open to.

And it's not like C++ keeps you from leaving resources hanging around. I 
have a C++ program right now that you sure better make sure the client 
can talk to the server, because if it can't, the client leaves the 
broken socket open, only to run out of sockets and crash out some time 
later.

I "fix" this by exec'ing the program in a separate process from a 
program in a GCed language, watching for the debug output to stop, and 
respawning the program when it dies. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Simply let lazy evaluation read the file as required, and the GC can 
>> delete the data you've already processed transparently behind you.
> 
>   That's not possible if the file is indeed read into one single string.

My guess is that internally it works the same way you'd do it from C: 
you read a buffer, walk thru the buffer, and then discard the buffer. 
There's no reason it can't work that way, just because it *looks* like a 
list of characters at the program level, any more than getchar() really 
reads one character at a time.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Here's the thing: If you could find all the root pointers in a C++ 
> program and know which things pointed to what, you could add GC to C++ 
> pretty easily without losing any functionality. GC is a strict superset 
> of what C++ gives you, avoiding much of the copying and most or all of 
> the errors that C++ leaves you open to.

  Let's wait for the new C++ standard and see what compilers come up
with... :)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> My guess is that internally it works the same way you'd do it from C: 
> you read a buffer, walk thru the buffer, and then discard the buffer. 
> There's no reason it can't work that way, just because it *looks* like a 
> list of characters at the program level, any more than getchar() really 
> reads one character at a time.

  If a string is really internally a list of smaller strings, wouldn't GC
become more difficult because you can actually have "references" pointing
to the middle of such strings and not their base?

  I must admit, though, that I don't know how GC is implemented.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> That didn't really answer the question of whether it is able to drop
> the parts which are no longer used.

no, I don't think readFile per se is a great means of working with large files.
It binds the whole contents as a string to a "variable" and even if you process
it by reading only a few chunks, the already read content is supposedly being
accumulated in the binding "variable".  I don't think if you go back and read
chunks from the beginning of the string the function actually goes back and
performs IO to read that position again.

laziness is great for highly abstract algebraic datatypes, but not that great
for IO.  For that, you have buffered IO just like in other languages (except
for being monadic).

Post a reply to this message

Warp wrote:
>   If a string is really internally a list of smaller strings, wouldn't GC
> become more difficult because you can actually have "references" pointing
> to the middle of such strings and not their base?

You'd have to implement that kind of reference as a base+offset sort of 
thing. Or buffer it and copy it into a list as needed, like building up 
something from multiple reads of C stdio.

>   I must admit, though, that I don't know how GC is implemented.

No, you're right. The kind of GC that can handle arbitrary pointers is 
called "conservative GC" if I recall correctly.  It works pretty poorly.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message