At 02:51 PM 12/27/00 -0800, Damien Neil wrote:
>On Wed, Dec 27, 2000 at 05:17:33PM -0500, Dan Sugalski wrote:
> > The part I'm waffling on (and should ultimately punt to Larry) is what to
> > do with lazy data, and what exactly counts as lazy data anyway. For
> > example, tied variables certainly aren't passive data, but should they be
> > evaluated if they aren't used? If you do this:
> >
> > ($foo, $bar) = (@baz, "12", 15, $some_tied_scalar);
> >
> > should the FETCH method of $some_tied_scalar be called unconditionally,
> > even though we don't use it? (I'd argue yes, but prefer no... :)
>
>I would argue no. If the list is evaluated lazily, I'd only expect
>the scalar FETCH method to be called when needed, not unconditionally.
While we can evaluate the list lazily, that doesn't mean that's what the
language guarantees. Right now it's perfectly OK to do:
$foo = ($bar, $baz, $xyzzy);
and if $bar and $baz are tied, that'll execute their FETCH methods. If
that's expected (and it is with functions, though arguably function calls
and fetches of active data are not the same thing) then we can't be lazy.
I'd *like* to be, since it means we can optimize away things or defer them
until never, but... (Plus it makes the dataflow analysis a darned sight
easier, since every load and store from a variable wouldn't potentially be
a function call...)
> > Also one side-effect of this, if we allow it, is to have a list masqerade
> > (under the hood, at least) as another variable type. We could, say, see
> this:
> >
> > @foo = (@bar, @baz);
> >
> > but actually defer evaluating the list and doing the assignment until
> > either @foo, @bar, or @baz is accessed. (Potentially holding off even
> > further--things like scalar() on @foo, for example, wouldn't require
> > finishing the assignment, and neither would something simple like $foo[12])
>
>I dislike this. It means that an exception occurring while evaluating
>$bar[0] can be deferred indefinately.
This is a good argument for tagging tied variables as active data, since
that'd require things be evaluated immediately.
>I'm also thinking that there
>could be some really odd interactions with GC...if I write
>
> {
> my @bar = some_creation_function();
> @foo = (@bar);
> }
>
>I would expect @bar to be GCd (or at least become GC-able) upon exit
>from the block. With a scheme as you describe, @bar would need to
>hang around for the lifetime of @foo.
Sure, and it would be. That assignment wouldn't get evaluated
lazily--instead we'd copy a few pointers and toss the old contents of @foo
instead.
In the case of:
@foo = (@bar, @baz);
we'd immediately toss the contents of @foo (as you'd expect) and replace
@foo with a link to the list holding @bar and @baz. They'd not be GC'd
immediately, but that's OK since they *shouldn't* be--they're not dead yet! ;-p
>I like lazy evaluation, but I don't think it should come at the
>expense of early detection of errors and comprehensible garbage
>collection.
We're trying really, *really* hard to decouple GC with object destruction.
The latter should be reasonably understandable (though not necessarily
deterministic) while the former should be considered Dark Magic. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
