Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment

From: "Chaim Frenkel" <[email protected]>
Sent: Thursday, August 24, 2000 2:42 PM
Subject: Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit
assignment


PRL> Therefore, the definition of the return function must be changed
PRL> such that it is lazy.

PRL> Additionally, the definition of assignment must not normally
PRL> evaluate a lazy expression, but rather evaluate it to the point
PRL> where its value would become the value of a B<variable>, and then
PRL> assign to that variable.  If the expression cannot be evaluated
PRL> to that point, (for example, C<$x+3>), then it may be an error to
PRL> assign to it.

> If I understand you correctly the actual target of the assignment
> would be delayed.
>
> Which leads me to ...
>
> {
>   my $foo = lvalue_with_lazy_return;
>
>   $foo = 42;
> }
>
> I wouldn't want the 42 going, who knows where. I want the value of $foo
> replaced with 42.
Blast.  OK, I wanted to make assignment oblivious to lvalueness, but that
scheme doesn't seem to work.  It does indeed "rub camel hair the wrong way".

If those two paragraps (and the two after them) are replaced with <<CUT,
what's still wrong with the RFC?
Therefore, return values of lvalue subs stay as their final GV, which is
passed into the assignment, and is then assigned to the rvalue.
CUT

(Note that "stay as their final GV" is equivlent to that whole long
paragraph, I think.  I'm not too good at internals yet (but I'm trying to
learn).)

    -=- James Mastros