Matt Fowles wrote:
>
> All~
>
> I have been following the whole GC/timely destruction thing for a
> while and have a few questions/observations.
>
> Most of the ref counting systems provide for very simple ref counting
> containers and, essentially, provide timely destruction for the simple
> case where a variable is not placed into some more complicated
> container. It seems to me that if we are worried about the simple
> cases like
>
> sub foo {
>
> my $bar = open "bar.txt";
> yada;
> yada;
> yada;
> }
>
> why not just have the compiler detect that $bar was not placed in a
> more complicated container and generate the code to close $bar at end
> of scope.
Hmm... this might be doable. Lemme think about it.
Firstly, the compiler needs to know that open() always returns an object
which needs timely cleanup. Easily doable through open()'s prototype,
since this of course describes traits/properties of the return value(s)
of the subroutine, amongst other things.
Second, the compiler needs to see that we never store into the $bar
variable anything which *doesn't* need timely destruction. Obviously,
we need to examine all assignments to $bar, and, check that $bar is
never passed into a subroutine through an "is rw" parameter. Again,
this is easily doable. (It *could* be passed to a sub through an "is
rw" parameter, if the compiler does all the same checks on that paramter
in that sub as it is doing in this scope).
Third, we need to make sure that all subroutines that we pass $bar to
*won't* store it in a complicated container. Note that all io
operations are subroutines... so you can't just say, "don't pass it to
subroutines," since then $bar is useless. How do we do this? Well,
again, it would have to be through the subroutine prototype -- the
parameter that we're passing $bar as would need to have some trait or
property attached to it saying that it won't get stored in a persistant
aggregate... I think this may be doable, and in fact the compiler could
*probably* detect this automatically, in sufficiently simple cases.
> This will provide timely destruction in the simple and common case.
Which is good.
> For more complex cases timely destruction will not be assured.
Which is not-so-good. We'd like timely destruction *always*
However, given that your suggestion can be implemented purely through
compile time behaviors, there's no reason we can't use what you've
suggested for the simple case, and some *other* solution for more
complex cases.
> Is there some glaring logical problem that I am missing here?
Not that I can see.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
