I'm sorry that I'm the one that has to tell you this, but people start programming the year 2004 and I believe we can expect more people to start programming in the future. I bet someone somewhere just recently wrote his first hello world program. So I'm not surprised that issues like this is brought up again. Most of us has different stages we go through as a (Perl) programmer. Giving this any serious consideration may be one of them. This isn't a trivial issue for many, and trying to understand how it currently works is something that should be encouraged IMHO as it'll give greater understanding for how Perl works, even though the behaviour isn't defined. All kinds of enlightenment should be encouraged and not ridiculed.

And there you have it. Works as in C.

Unfortunately, not everyone knows C.

You have apparently spelled this out several times, so I recommend you to send a documentation patch for perlop that clarifies what "as in C" really means if this upsets you so much. Then you've done some real good. Frankly, I don't see what there is to get upset about. He is just a guy that wants to explore Perl.

ihb

Let me rephrase Abigail-II's answer, in easy-to-follow steps.
1. The pre- and post-increment are documented somewhere.
2. That documentation is in perlop.
3. Perlop says "If you do X in Perl, it is the same as doing X in Foo".
4. The documentation for Foo (which is as easily obtainable as perlop) is that doing X has (deliberately?) undefined behavior.

The documentation is complete. The problem isn't a problem. That the documentation refers to other documentation may be annoying, but it is complete. And, whether you like it or not, every single person who worked/works on the Perl sourcecode and nearly everyone who worked/works on the Perl design is fluent in C and has no problem with statements like that. In other words, any single person who would have ever worked on the documentation is fluent in C and has no problem with statements like that.

. . . so I recommend you to send a documentation patch for perlop that clarifies what "as in C" really means if this upsets you so much.

Ah, but he's not the one who's upset by the documentation. You are. He (and I) is upset by your unwillingness to read said documentation.

An analogy - if you were to pick up a textbook on calculus, it would assume you knew how to do algebra. Would this bother you? What if it said "The edge cases of this transformation are similar to this transformation as done in Set theory."? Because, frankly, that's what perlop is saying. "The edge cases of the pre- and post-increment operators are the same as in C."

Let's look at something else - the reason why it's the same as in C. Because Perl is implemented in C! Do you really think the Perl developers reinvented the wheel here? No! They delegated to the source language, because that's the behavior they were looking for. And, if the ANSI C standard ever changes how this edge case behaves, then Perl will have that change as a matter of course. Hence, the reason to refer to the C documentation. It's very OO in its thinking. We inherit from C and delegate back to C.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

First of all, ihb is not someone who wouldn't read the C docs if the Perl docs told him to. He is arguing on behalf of beginners, and those without a C background, etc.

Second, your analogy has a fallacy: algebra is a pre-req for calculus, but C is not a pre-req for Perl. A person going into Perl first of all languages is not expected to know C (or sed, or awk, or sh!). Therefore, depending on just what behavior it is they have to refer to C for, they might not understand what it is they're reading, because it'd be in a C context, not a Perl context. Besides, how much of Perl behaves like some language from which it is derived? Why don't we bundle the docs from those other languages with Perl, so Perl's docs can merely cross-reference theirs?

One problem I see is that while Perl is written in C, Perl does things differently than C. For one, Perl handles this pre-inc and post-inc thing differently. The documentation says the behavior is undefined, but it had better NOT say the behavior is undefined, "just like in C", because it is obviously not. I think Perl's docs need updating, in this case. I think the behavior is definable, we just haven't written it down to define it.

Instead of yelling at the original poster for venturing into the forbidden zone... I don't know. Something. Just don't chastise him for experimenting with the language and reporting his findings. He's learning. Let him learn.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

The documentation is complete. The problem isn't a problem. That the documentation refers to other documentation may be annoying, but it is complete. And, whether you like it or not, every single person who worked/works on the Perl sourcecode and nearly everyone who worked/works on the Perl design is fluent in C and has no problem with statements like that. In other words, any single person who would have ever worked on the documentation is fluent in C and has no problem with statements like that.

There are several incorrect statements there, but I'd just like to say that I at least have a problem with such statements in the documentation. They don't belong, and should be fixed; it's just a very low priority to me.

And so we are expected to tolerate everybody who starts programming in 2004 not referring to anything written before 2004? We are supposed to accept that manuals don't exist? We are supposed to accept that new suers will ask questions without even considering that they are not the first to come across some thing or another?

Well, like it or not, there is a body of knowledge out there.

When the manual says that the behaviour of something is udefined, then it also implies " and it may come back to bite you if you try to use it".

Enlightenment is welcomed, but the answer to the question is clear, it is documented. It is written in plain English for all to see.

jdtoronto

Right, my point was that one shouldn't read documentation. sigh

I could try to explain my point again more clearly, but I don't know how.

Enlightenment is welcomed, but the answer to the question is clear, it is documented. It is written in plain English for all to see.

And I wrote my argumentation in plain English for you to see, but you still didn't get it. And that's the problem, isn't it? What's clear for you may not be clear to someone else.

If you take the time to read my post again, please read it in the context of Abigail-II's reply. Argumentation is always in a context.

ihb

And understanding how it is working currently is valuable in forming an in-your-head model of what perl actually does with your code.

(Notwithstanding that, constructs with undefined behavior should not be used in real code.)

Good morning Abigail.

Looking up the word "behaviour", I find that it relates to "actions" and "reactions". Things that have happened. Actions that have taken place. Past tense.

Saying that behaviour is undefined, makes no sense. Until something has happened it isn't behaviour.

If you predict that a certain thing will (future tense) display a certain behaviour, and you get it wrong. It didn't display the "wrong behaviour", or "no behaviour". The action the the thing displayed (past tense) was the behaviour. You were simply wrong in your prediction.

Therefore, you can't say a "behaviour is undefined", because an action or reaction doesn't become behaviour until it has happened, and when it has happened, it can be measured, and is therefore not "undefined".

It may not be predictable--though in this case, I (rashly) bet the outcome has been the same since Perl 1; maybe you would confirm that?--which kinda makes it a bit predictable.

It may also be unexplainable. Which may explain why the explainations are so lacking.

It is, however, OBSERVABLE! Huge red font omitted.

If a phenomena can be observed, it can be questioned. The strongest defining impulse of the human being over our non-sentient co-inhabitants, is the ability and need to ask the question WHY?.

You may well be correct in reaching your conclusion that asking why is not "worth your effort" or "likely to result in a you reaching a satisfactory conclusion", but that is your conclusion. It satisfies your criteria.

Is it your assertion that because you have reached a conclusion that satisfies you, that noone else in the entre world is allowed to think about this, or discuss it any place where you might observe that discussion?

"Results are undefined" in Computer Science means, "the documentation is not going to explain what you'll get in Tuesday's version of the compiler on John's favorite machine."

In the case of keys %foo, the results are defined: you will get all keys. The order they're returned is defined but poorly so: it's a mistake for documentation to say they are returned in "random order," because the order has nothing to do with a PRNG. It would be better to say the order is not defined, as that is more accurate. Tuesday's compiler on John's machine will produce something inconsistent with your own experiments.

In the case of ++$m + $m++, the results are undefined: no documentation claims to give an authoritative answer on such expressions, and some documentaion will specifically disavow any predictable results.

For those who do not program in C, here's the gist of the action. The do { my $x = $m; $m++; $x } mechanism is not a sufficient postincrement operator, because real post-incrementation happens after the rest of the expression. However, the specific moment that is defined to be after the rest of the expression is not clearly defined; various versions of a C compiler will differ, and various hardware platforms may also have something to say about it. It's undefined.

--
[ e d @ h a l l e y . c c ]

By 'undefined', I think the traditional comp-sci meaning of "you may get anything or nothing" was meant. There's no telling what will happen, and whatever does happen may change over time as new compilers and libraries are implemented.

I think the more accurate Comp-Sci phrase is "not well defined".

For any given implementation, you can tell what will happen, because it is very unlikely to vary from what happened last time on that same implementation.

It may well vary with other implementations.

The implementers may (and do) choose not to define the behaviour.

1. Because it may vary across implementations.
2. Because the explanation my not appear logical or rational.
3. Because it isn't a useful behaviour.

Mostly, because if they do define the behaviour, then

1. they will have to ensure that the defined behaviour is consistent across platforms and versions.

   Which if the behaviour is generally non-useful, and is likely to be influenced by things (like compilers) beyond their control, then the extra work that this would commit them to is not worth it.

2. the defined behaviour will have to be defendable and defended.

   Also a waste of energy for what is essentially a non-useful behaviour.

But given the OP's disclaimer; statement that this was purely an academic exercise; etc.; his being condemned on the basis of a non-sequitous statement, and a short phrase in an obscure document that the behaviour "is same as C"--where it may be defined as not being well-defined, but my attempts to located such definition in K&R or Waite Group's guide haven't located it--hardly seems justified.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

That is not entirely the case here though. See the following code and output.

my $f = 1;
print '$f = ', $f, ' and $f + $f++ = ', $f + $f++, "\n";

my $g = 1;
print '$g = ', $g;
print ' and $g + $g++ = ', $g + $g++, "\n";

__END__
$f = 2 and $f + $f++ = 3
$g = 1 and $g + $g++ = 3
[download]

This is not the expected behaviour in C and i'm only auto-increment/decrement a single time.

What is undefined is the order of operation. Since ($f + $g++) == ($g++ + $f) this is normally a reasonable assumption, but of course ($f++ + $f) != ($f + $f++).
-- gam3
A picture is worth a thousand words, but takes 200K.