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.

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:??;

I think the behavior is definable, we just haven't written it down to define it.

I think you don't understand the idea behind the concept of "undefined behavior" in language specifications. It doesn't mean that the language will use a random number generator to give you an unpredictable result every time. In most cases, you'll find that the behavior is perfectly reproducible, and you could think of documenting it. Don't do it! Undefined behavior means that compiler writers has the freedom to choose whatever behavior they want, and the users of the language SHOULD NOT rely on the way the behavior is "defined", because the compiler writer has the freedom to change it in the next version.

It's just like saying: cool, this module has this interesting undocumented variable! Let's use it! If you use it, it's under your own risk. The documentation is like a contract. And please don't send a documentation patch to the author before making sure that it's not undocumented for a reason.

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.

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