On Wed, Dec 27, 2000 at 09:27:05PM -0500, Dan Sugalski wrote:
> 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...)
I'd view the function call case as being conceptually equivalent to:
@_ = ($bar, $baz, $xyzzy);
&snrub;
In this case, you are assigning the arguments to an array (@_), so it
makes sense for them all to be evaluated. (Or not, depending on your
opinions of how list-to-array assignment should work. :>) In the case
of assigning a list to a scalar, or a list of scalars, I still think
that it makes sense for values not assigned to not be evaluated.
Consider this case:
($two, $four) = (@primes, $junk);
@primes is a lazy array containing all the primes. Here, you would
expect only the first two values of @primes to be evaluated. If
evaluation stops with the second element fo @primes, however, why
would $junk be evaluated?
> > > 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.
If this isn't done for tied variables, I withdraw my objection. I'm
still a bit dubious about the cost/benefit tradeoff here, though.
Hmm.
# @primes = (2, 4, 5, 7, ...)
@foo = (1, @primes);
I think the above constitutes an argument for something. I'm not
certain what. :>
> >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. :)
My specific concern is that it shouldn't be easy to accidentally
leave very large data structures lying around without obvious
references to them. GC need not be deterministic, but it should
be possible to avoid leaking memory without resorting to animal
sacrifice. :>
- Damien
