At 09:45 AM 12/28/00 -0800, Damien Neil wrote:
>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.
Function calls are easy. It's potentially active data that makes the flow
analysis.... interesting. When every variable that originates from outside
a sub is potentially active, it makes for a rather pessimistic view of some
of the world.
>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?
Well, because it's active and perl currently says that it evaluates all the
elements of a list before assignment. I'm not arguing that this is optimal,
but it is one of the things perl 5 does.
One thing I did think of earlier is that lazy evaluation means that lists
can be iterators. Right now we optimize 1..1000 in foreach loops, but we
could theoretically do it anywhere. (If Damian's lazy sub stuff gets in I
expect we'll piggyback on top of it, and I hope it does)
> > > > 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. :>
Funky optimizer magic. I'd optimize that to (in pseudo-perl-assembly):
acopy foo, primes
unshift foo, 1
rather than
aclear foo
apush foo, 1
apush foo, primes
since the copy is probably faster than the push. (Well, maybe at least)
> > >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. :>
I don't think we need to worry about that. One of the things I want perl 6
to do is to hijack variable guts whenever possible in assignments. For
example, this:
@foo = @bar;
could be set so that perl just copies the relevant data from @bar's PMC
into @foo's PMC. (This only works if there's only one copy of @bar done and
no references, but that's not too unusual) @foo's contents would need to be
GC'd, but not @bar's, since it's still active. The same holds for lists
that are evaluated lazily--the target variable gets cleared, but the source
variables in the list still exist and while they take up space, it's space
that's going to be taken up regardless.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
