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.
> 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. 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.
I like lazy evaluation, but I don't think it should come at the
expense of early detection of errors and comprehensible garbage
collection.
Other than that, I like what you describe.
- Damien
