|
 |
nemesis <nam### [at] gmail com> wrote:
> Warp escreveu:
> > Invisible <voi### [at] dev null> wrote:
> >>>> - We might finally get concurrent GC too.
> >>> amazing news, huh?
> >>>
> >>> concurrent GC is almost as hard as solving a halting problem... ;p
> >
> >> Have *you* tried it? :-P
> >
> >> Seriously, analysing the structure of a huge chunk of data while it's
> >> still being modified is no picnic.
> >
> > If Haskell requires a garbage collector, it means that objects are not
> > strictly scope-bound (in other words, objects can outlive the scope where
> > they were creted, rather than being automatically destroyed when the scope
> > ends). This, consequently, means that objects are not handled by value, but
> > by reference (or pointer, or whatever you want to call it), which is a
> > requirement if you want to share the same object with more than one other
> > object. I know next to nothing about Haskell, but the little I have seen
> > doesn't look like it would be reference-based code. It *looks* to me like
> > everything is handled by value.
> >
> > Could give a simple example which demonstrates the need for a GC?
> kinda weird your reasoning there. Java passes things by reference and
> still needs a GC.
Isn't that what I said above? You write as if I had said the exact
opposite (ie. that languages using references don't need GC).
> I don't quite see the linking between the need for a
> GC and passing things by reference or by value.
If you handle objects by reference, and you can pass references around,
it means that objects can be shared and that the lifetime of these objects
is not bound to the scope where they were created. If objects outlive the
scope where they were created, you need some kind of GC to destroy them
(unless the language is such that leaking objects is ok).
--
- Warp
Post a reply to this message
|
 |