Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^3: Quantum Weirdness and the Increment Operator

by dragonchild (Archbishop)
on Jun 24, 2004 at 12:23 UTC ( #369310=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Quantum Weirdness and the Increment Operator
in thread Quantum Weirdness and the Increment Operator

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


Comment on Re^3: Quantum Weirdness and the Increment Operator
Re^4: Quantum Weirdness and the Increment Operator
by japhy (Canon) on Jun 24, 2004 at 13:37 UTC
    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:??;
      Just don't chastise him for experimenting with the language and reporting his findings. He's learning. Let him learn.
      Oh, goodie. Now that's helpful! Anyone who's experimenting with the language, we just let them go, and admire them from a distance, keeping silent.

      And then we wonder why people stop programming in Perl because their production code failed in mysterious ways. They walked into a swamp, and we let them, cause that will "teach them".

      Now please excuse me, I've some "dangerous curve" signs to remove.

      Abigail

        You are misinterpreting me. I did not say to "let them go", "keeping silent". I said not to chastise the orignal poster for saying "this code confused me, so I tried to find out why it works the way it does, and this is what I found out".

        Certainly, tell him not to use that kind of construct in his production code, and tell him that the documentation does not provide a defined behavior for it, but don't be angry or impatient with him.

        And you've blended "learning" with "doing in practice". Just because I learn something (like how crazy this ++X and X++ business is) does not mean I'm going to employ it. Some "swamps" need to be investigated for signs of life, but that doesn't mean the scientist needs to live in the swamp.

        _____________________________________________________
        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.

        But I don't think this behavior should be changed, unless you were to change how Perl uses its variables entirely! It works naturally (that is, following a set of natural rules) due to how Perl itself works (that is, due to Perl's set of rules).
        _____________________________________________________
        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:??;
Re^4: Quantum Weirdness and the Increment Operator
by ysth (Canon) on Jun 24, 2004 at 18:12 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://369310]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2014-09-01 13:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (12 votes), past polls