>>> The point is that there is no way for a compiler to decide.
>>
>> ....which is why you have the hints... ;-)
> 
> Or iterative optimizations, like big SQL servers do.

Mmm... big SQL servers do this because which method is faster *strongly* 
depends on the exact data being queried. It's just not possible to make 
reasonable decisions at design-time, it must be at run-time.

I'm not sure all programs face quite such colossal challenges as an SQL 
system... ;-)

Post a reply to this message

>  That didn't really answer the question of whether it is able to drop
> the parts which are no longer used.

The answer is yes, mostly.

Data is automatically destroyed as it goes out of scope. So if you
have a process that works one line at a time, then one line at a time
will be disposed, if you have a process that works on single chars
then one char at a time is disposed.

In general, Haskel takes some input to a function,
produces some new data output in fresh memory,
and then disposes of the input,
and frees that memory if no other function references it,
eventually GC reclaims the memory. (or you can
manually trigger a GC if you want).

File IO is imperative, so it can be treated in manners
typical of other languages. You don't need to bind >>=
files to processes, it's perfectly OK to read one line
at a time and do something with it until the EOF is reached.

Post a reply to this message

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