This bit, in particular, could easily be changed with a small cahnge to the optimizer, or optree generator. That it hasn't happened is mainly because nobody's bothered. (Well, because that part of the code's reasonably scary) Because of the way that perl works internally, both the pre and post increment versions of that code could easily resolve to 6.

Trust Abigail here. Don't count on the behaviour of multiple manipulations to a variable without an intervening sequence point.

Only what the standard, or the documentation, guarantees is valid to count on. Everything else should be considered a quirk of the implementation.

Shouldn't there be a lot more documentation, then? Increments and decrements are not the only things being documented vaguely.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

Yep, there should be, or at least more specific docs on how things should act. Perl is awfully fuzzy about the behaviour of a lot of things. (Witness the fact that perl only recently nailed down the behaviour of numeric operations)

As a for example, in this:

  $a = $a + $a++;
[download]

what should $a equal at the end? And if $a is tied or overloaded, what order should the tie/overload stuff be called in?

The two of you obviously mean different things by "defined".

Abigail says that $i = $i++ is undefined because it is not declared in the Perl (or C) language specs. Juerd says that it is defined because it has consistently behaved in the same way for as long as anyone can remember.

In my experience, Abigail's definition of definedness is the one most commonly (and, many would argue, most properly) used in this context. While the behaviour of $i = $i++ may be deterministic, the fact remains that its behaviour is merely an artifact of how it is implemented and should not be relied upon, because, without any implementation-independent specification of its behaviour, next release of perl is free to arbitrarily change it for any reason (or no reason at all).

Please do provide a pointer to the documentation that garantees things will happen this way. All $i ++ is saying that $i will be incremented after the value is returned. But it is nowhere specified that $i will be incremented before or after an assignment. Its behaviour is UNDEFINED.

(And if you consider this a flame, please take your question to comp.lang.c (before you say "Perl isn't C", look up the discussion of ++ in perlop. It says that it works as in C) and really learn what being flamed is.)

Abigail

a pointer to the documentation that garantees things will happen this way.

There is none.

9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. [...]

If you want guarantees, do not use Perl.

But it is nowhere specified that $i will be incremented before or after an assignment.

$i = $i++ is deparsed to ($i = ($i++)). Having $i tied and assigning to another tied variable tells me the increment happens before the assignment.

look up the discussion of ++ in perlop. It says that it works as in C

Perlop is wrong. Did the authors of Perl re-create all compiler/platform specific postincrement issues that exist in C? If not, how can its behaviour ever be the same?

nowhere specified that $i will be incremented before or after an assignment

perl's sourcecode is the specification - MANY things are not defined in the perldocs. And fortunately, this is compiler/platform independent. Anyway. Here's your specification:

PP(pp_postinc)
{
    dSP; dTARGET;
    if (SvTYPE(TOPs) > SVt_PVLV)
        DIE(aTHX_ PL_no_modify);
    sv_setsv(TARG, TOPs);
    if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP
+OK(TOPs)
        && SvIVX(TOPs) != IV_MAX)
    {
        ++SvIVX(TOPs);
        SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK);
    }
    else
        sv_inc(TOPs);
    SvSETMAGIC(TOPs);
    if (!SvOK(TARG))
        sv_setiv(TARG, 0);
    SETs(TARG);
    return NORMAL;
}
[download]

PP(pp_preinc)
{
    dSP;
    if (SvTYPE(TOPs) > SVt_PVLV)
        DIE(aTHX_ PL_no_modify);
    if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP
+OK(TOPs)
        && SvIVX(TOPs) != IV_MAX)
    {
        ++SvIVX(TOPs);
        SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK);
    }
    else /* Do all the PERL_PRESERVE_IVUV conditionals in sv_inc */
        sv_inc(TOPs);
    SvSETMAGIC(TOPs);
    return NORMAL;
}
[download]

Pay special attention to dTARGET, sv_setsv and SETs in the postinc. As you can see, Perl does not delay the increment, but it does save the old value. (Which is because Perl can not optimise the same way C compilers do. At compile time, Perl cannot be sure if $i is a normal scalar or something special.)

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

The fact that it deparses as ($i = ($i++)) does not say anything. It still will not say anything about the order in which the assignment and the increment are done.

Did the authors of Perl re-create all compiler/platform specific postincrement issues that exist in C?

Why should they? All they had to do was follow the specifications. And the specification say that the code we are talking about has undefined behaviour.

MANY things are not defined in the perldocs.

And are hence subject to change without a deprecation cycle. Even the smallist patch might radically change the behaviour, including attempts to erase all the files from your disk. That's the nature of undefined behaviour.

Abigail