Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Timely destruction

3 views
Skip to first unread message

Dan Sugalski

unread,
Jun 3, 2003, 9:15:13 PM6/3/03
to perl6-i...@perl.org
Or not.

Folks, I know this is the perennial thread, or one of them, so before
I get too cranky, let me be kinda clear.

We aren't doing refcounting. We are continuing with the current
scheme as implemented. We're not looking to do anything to change
that scheme except perhaps implementing a generational or continuous
garbage collection system.

Unless Larry mandates dead-on timely destruction for Perl 6, and he's
told me end of block or end of sub is fine so far, refcounting isn't
an option.

Thanks. No, I don't really want to discuss this.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Garrett Goebel

unread,
Jun 4, 2003, 10:56:54 AM6/4/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:
>
> We aren't doing refcounting. We are continuing with the current
> scheme as implemented. We're not looking to do anything to change
> that scheme except perhaps implementing a generational or continuous
> garbage collection system.

Last I checked Python used refcounting... How can we claim to support Python
without refcounting?


> Unless Larry mandates dead-on timely destruction for Perl 6, and he's
> told me end of block or end of sub is fine so far, refcounting isn't
> an option.

I wandered across some C# docs that describe a method to both work with
exception handling and insure timely destruction... Its nothing new. And it
only garauntees the timely destruction at the end-of-block, not when last
reference is released. But it is interesting to see how others do it.

using ( type variable = initialization ) embedded statement

which expands out to:

{
type variable = initialization;
try
{
embeddedStatement
}
finally
{
if (variable != null)
{
((IDisposable)variable).Dispose();
}
}
}

So using 'using' requires that the variable/object in question implement an
explicit 'Dispose' method and in use might look like:

using (TextReader reader = new StreamReader(filename))
{
string line;
while ((line = reader.ReadLine()) != null)
{
Console.WriteLine(line);
}
}

Or poorly perl6-ified:

using $reader = IO.new($file) { print while $reader };


Couldn't parrot divorce itself from the timely destruction issue and punt
that to the higher level languages? Require the HLL or programmer to call an
explicit destructor, and have parrot's idea of timely destruction be limited
to the HLL forcing garbage collection...

--
Garrett Goebel
IS Development Specialist

ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com

Dan Sugalski

unread,
Jun 4, 2003, 11:31:04 AM6/4/03
to Garrett Goebel, perl6-i...@perl.org
At 9:56 AM -0500 6/4/03, Garrett Goebel wrote:
>Dan Sugalski wrote:
>>
>> We aren't doing refcounting. We are continuing with the current
>> scheme as implemented. We're not looking to do anything to change
>> that scheme except perhaps implementing a generational or continuous
>> garbage collection system.
>
>Last I checked Python used refcounting... How can we claim to
>support Python without refcounting?

Easily--Python does *not* claim timely destruction. I've asked Guido,
and he's been pretty adamant about that.

> > Unless Larry mandates dead-on timely destruction for Perl 6, and he's
> > told me end of block or end of sub is fine so far, refcounting isn't
>> an option.
>
>I wandered across some C# docs that describe a method to both work
>with exception handling and insure timely destruction... Its nothing
>new. And it only garauntees the timely destruction at the
>end-of-block, not when last reference is released. But it is
>interesting to see how others do it.
>

>Couldn't parrot divorce itself from the timely destruction issue and
>punt that to the higher level languages? Require the HLL or
>programmer to call an explicit destructor, and have parrot's idea of
>timely destruction be limited to the HLL forcing garbage
>collection...

That's what the lazysweep support does.

0 new messages