develooper Front page | perl.perl5.porters | Postings from January 2001

Re: [PATCH] lvalue hash and array elements

Thread Previous | Thread Next
From:
Simon Cozens
Date:
January 4, 2001 03:33
Subject:
Re: [PATCH] lvalue hash and array elements
Message ID:
20010104113304.A29388@deep-dark-truthful-mirror.perlhacker.org
On Wed, Jan 03, 2001 at 11:31:09PM -0800, Stephen McCamant wrote:
>     if (PL_op->op_private & OPpMAYBE_LVALUE)
>         lval = cxstack...;

OK, light has dawned, and you're right. Sort of. :) What you're admitting
here is that you need both a run-time and a compile-time check. You need
the run-time check because you don't know whether or not you're being called
as an lvalue or an rvalue, and nothing about the sub's op tree can tell
you that. You need a compile-time check to tell if this op is likely to
be a return value. 

We need a combination of two checks, which is what you do above, and what my
LVRET macro also does. So we agree there. 

We also agree on what the compile-time check must be. So all we disagree on is
what the run-time check must be.

However, I have a correctness problem that neither of us noticed. :) 
I failed to take into account the fact that

    if($a){$b}{$c}

looks like:

UNOP (0x814dd80) leavesublv
    LISTOP (0x814ef18) lineseq
        COP (0x814eed8) nextstate
        UNOP (0x814eeb8) null
            LOGOP (0x814ee90) and
                UNOP (0x814ed40) null [15]
                    SVOP (0x814e0a0) gvsv  GV (0x814cb80) *a
                LISTOP (0x8148fc8) scope
                    OP (0x814ee50) null [174]
                    UNOP (0x814ee30) null [15]
                        SVOP (0x814ed60) gvsv  GV (0x8142f3c) *b
        COP (0x814f0f8) nextstate
        BINOP (0x814f0d0) leaveloop
            LOOP (0x814f098) enterloop
            LISTOP (0x814f070) lineseq
                COP (0x814f030) nextstate
                UNOP (0x814f010) null [15]
                    SVOP (0x814ef40) gvsv  GV (0x814cbc8) *c

See, the next op for the gvsv *c is not leavesublv, but leaveloop,
so my patch won't see that as an lvalue return. So you are right, we
need something to descend the op tree and label this as a return value.

And I think I understand your marking scheme, and it doesn't look like
it would be hard to implement. (I was getting confused by trying to do
it all using op_next; using mod() is the Right Way to do it.) 

The only thing that upsets me slightly is that you're using up a flag,
but now I come to look at it, 8 looks free.

Do you have time to produce a patch?

-- 
"He was a modest, good-humored boy.  It was Oxford that made him insufferable."

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About