Front page | perl.perl5.porters |
Postings from January 2001
>>>>> "SC" == Simon Cozens <simon@cozens.net> writes:
SC> On Thu, Jan 04, 2001 at 11:08:12PM -0800, Stephen McCamant wrote:
SMcC> * Checking for real syntactic lvalue-ness significantly narrows the
SMcC> range of what subs can be lvalues.
SC> Hold on, you're not actually doing that. I don't see what you're
SC> doing that affects it, and if you are doing something that affects
SC> it, stop. :)
I'm calling mod(). The whole point of mod() is to check at compile
time that its argument is an lvalue. shift is not an lvalue. At the
moment I've convinced myself that the status quo behavior of allowing
anything at all at compile time is broken. I don't think you should be
able to modify a sub's arguments by assigning to the result of a shift
returned as an lvalue, any more than you can change them by assigning
to the result of shift inside the sub. If you like being able to
assign to shift, I'd like to hear an argument why.
SMcC> - case OP_RETURN:
SMcC> - if (o->op_next && o->op_next->op_type != OP_LEAVESUBLV) {
SMcC> - o->op_seq = PL_op_seqmax++;
SMcC> - break;
SMcC> - }
SMcC> - /* FALL THROUGH */
SC> Uhm, why have you done that?
Uhm, because I deleted this thing it was falling through to, so that
it would otherwise just fall through to the default cases, which just
sets op_seq and breaks; no need to do that with two different pieces
of code.
SMcC> + if (cxstack[cxix].blk_sub.lval && CvLVALUE(cxstack[cxix].blk_sub.cv))
SMcC> + return cxstack[cxix].blk_sub.lval;
SC> return 1?
That would work too for the current use; since lval can hold several
flags, it seemed like we might as well return more information that
might be useful in the future.
-- Stephen McC
Thread Previous
|
Thread Next