Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Quantum Weirdness and the Increment Operator

by ihb (Deacon)
on Jun 24, 2004 at 10:30 UTC ( #369278=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^2: Quantum Weirdness and the Increment Operator
Download Code
Re^3: Quantum Weirdness and the Increment Operator
by dragonchild (Archbishop) on Jun 24, 2004 at 12:23 UTC
    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:??;
        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

        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.
Re^3: Quantum Weirdness and the Increment Operator
by jdtoronto (Prior) on Jul 23, 2004 at 18:02 UTC
    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

Re^3: Quantum Weirdness and the Increment Operator
by jacques (Priest) on Jul 23, 2004 at 18:34 UTC
    Unfortunately, not everyone knows C.

    Any self-respecting programmer knows C. It is only the most important and influential language of the last 25 years.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2014-12-28 18:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (182 votes), past polls