This feature should not be considered a feature because I am too stupid or lazy to figure out how it really ought to work, and I reserve the right to change my mind about it in the future, at which point everyone will be required to believe that the mess is all your fault, not mine, for charging in where the language designer fears to tread.

But that's kind of unwieldy and tiresome to type

But you're a programmer. Can't we get the computer to substitute the boiler plate ...

{Where is that number for the patents lawyer ...}

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

That's the kind of thinking that makes the C++ standard unreadable to most. I started out reading and memorizing^※ the original casually-written Annotated Reference Manual. As things got more formal, a casual word would be replaced with the more formal phrase, everywhere. Then more qualifiers were added, such as "non-cv-qualified" and so on. If you didn't already know what it meant, it's thick goo.

I would envision a spec that used clear and mostly terse terminology. Like Perl itself, make the most common terms short. Rather than a dozen adjectives followed by X, make that whole thing called something, and the less-constrained (rarely used) version be decorated instead.

—John

※: I impressed many, including Stroustrup himself, with my ability to name the chapter and verse where a particular feature was described, so everyone else at the table could turn to it. I was young then.

I think that the behavior is undefined is a phrase well known in the computer language world, and as such, I don't worry about the tense.

"The behaviour of X is undefined" is a well recognized phrase to indicate an action is unsafe. Common usage trumps logical analysis in practice (assuming you buy the logical analysis in the first place). "You must not do X" is an alternative (commonly used in internet standards).

I've also encountered "The behaviour is subject to change." (which is rather meaningless since everything is subject to change) and "One should not rely on the current behaviour.", but those have a different, weaker meaning. They imply the action is acceptable if a suitable upgrade strategy is in place.

Though BrowserUk makes an interesting and rigidly logical argument, in reality most people don't think the definitions through, they just follow common usage as they interpret it. So, in spoken language, common usage trumps all. It redefines academic convention and historical definitions. This is just how languages naturally evolve.

That said, behavior is synonymous to expected behavior in common usage (at least in U.S. English), thus its application in present and future tense is (IMHO) perfectly acceptable.

Hmm, maybe that's just a shortcut for saying that the specification for the behavior is undefined.

I think the phrases: "the behaviour is unspecified"; or "the behaviour is implementation dependant" are more appropriate.

The standardeze I recall from C and C++ is that "implementation dependent" means something else. I.D. means that a reasonable choice may be made by the implementer, and it will behave in a consistent manner within that system. For example, whether shifting is signed or unsigned.

But undefined meant that all bets are off. It could do bizarre things including destroy the computer or make zebras fly out of the USB port. Calling through a stray pointer exhibits undefined behavior. One famous example in DOS would make the printer start spewing stuff (a failed BOUND instruction would call INT 5, if memory serves. MS decided to use that for the print-screen key instead of its intended purpose. Random garbage executed as code would hit that byte eventually.)

Since Perl 6 is more "confined" than C, I don't expect to have that very often. More usually, the implementation can choose from a range of allowed behaviors.

Sometimes, the allowed "ill-behaved" behavior is hard to pin down. For example, if you random-access a lazy list generated from a map that you promised was injective and idempotent, and the mapping block decides to return other than 1 value at some point, I can expect that list to be messed up, but the virtual machine won't crash, and strange things won't happen to global variables, etc.

—John

So, that leaves "the behaviour is unspecified" to describe the situation that you otherwise describe as "a shortcut for saying that the specification for the behavior is undefined.". Seems good to me.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

It could do bizarre things including destroy the computer or make zebras fly out of the USB port.

That reminds me of a post I read in comp.std.c a long time ago:

> Now what happens if, oh, you do THIS:
>
> foo()
> {
> int x;
>
> x=10;
> if (x) free (&x);
> }
>
> I know that malloc uses heap space and that the local variables take up the
> stack, so what happens? &x is NOT null so it will try to free it, so what
> happens?

Shit happens. Exactly what shit happens depends on the implementation.
Since this is in the realm of undefined behavior a conforming implementation
is allowed to launch a pre-emptive strike against Iraq.


That was posted by Stanley Friesen on 1990-12-19, which is unfortunately older than what Google Groups has archived, so I can't give you a link to it.

Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.

I think the phrases: "the behaviour is unspecified"; or "the behaviour is implementation dependant" are more appropriate.

Not being a native English speaker I wonder - what's the difference between "unspecified" and "undefined" in that context? "undefined" means there are no specs. "unspecified" means there are no specs. What is it?

Shouldn't that be "the behavior is unpredictable" since predicting means foretelling something that will have happened at a later point in time?

Frankly, that's finickiness. What's that talking of "behavior" concerning computers, anyways? There's no such thing. Computers don't "behave", since they don't choose one reaction or another out of a set of possibilities at free (or bound) will, pondering the effect of that choice. Talking of "behavior" when it comes to computers is an anthropomorphism, an analogy, a metaphor - one of those, I'm not sure which, but I guess the first is most accurate. But being such, any adjective (or adjectival component?) to express what is meant, is fine IMHO - as long as it is understood.

The difference is that after the fact--ie. once the program is implemented and you can try a scenario and see empirically what happens--what happens is no longer undefined. But it remains unspecified.

Once you can create circumstances for which the specification does not define the expected effect, outcome or result, you can then see what actually happens. And once you know what actually happens, it is no longer undefined; just unspecified.

It is actually very rare that for any given set of circumstances, a computer program will result in a random outcome. In general, for a given set of inputs, you will get the same set of outputs/outcomes. Were that not the case, the whole basis of testing and test driven development wouldn't work. It is the very basis of debugging--hence the maintainers plea for minimum reproducible testcases. It's not always easy to determine the full input set, but they're the bugs that are most interesting--provided time pressure isn't too high.

Hence, it is usually possible to say that for build X of Y; doing Z will result in A. Even though it may not be specified; and that it might change with platform, implementation or build; and as such, should not be relied upon.

What's that talking of "behavior" concerning computers, anyways? There's no such thing. Computers don't "behave", since they don't choose one reaction or another out of a set of possibilities at free (or bound) will, pondering the effect of that choice. Talking of "behavior" when it comes to computers is an anthropomorphism,

Using the word behaviour in conjunction with computers is not anthropomorphising. Behavour can be simply defined as "the actions or reactions of an object or organism".

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

That's what BrowserUK was originally saying.

You find their meaning to be the same because you automatically assume "behavior is undefined" to "the documentation for this behavior is undefined". Some would say that this is indeed implied by context, since the entire document is referring to "the behavior" in some kind of weird literary timeless tense or imperfect tense.

But, I'm against evolving language out of stupidity or laziness. That is, don't misuse words if there is already a good and proper way to say it. If there isn't, then I'll consider it.

FWIW, doing bad things in Perl shouldn't be undefined to the same extent as C. The ill-effects should be bounded and the larger context fault tolerant. But specifying that in detail makes it legal and well-defined!

—John

I'd like to point out two things about that referenced post:

1. There were two audiences involved: those with C experience; and those (like the OP) for whom Perl is their first computer language.

   Relying upon knowledge of the specifications of another, more technical language as the explanation of Perl's foibles, is IMO, like telling a child they have synchronous diaphragmatic flutter, when they suffer a bout of a common childhood malady.

2. The phrase may be "well-known"--in very limited circles--but that does not make it logical, nor especially meaningful.

   It reminds me of those archaic legal phrases that still persist despite that few people ever really understood them, and almost no one does now. Eg. The term "larceny" persists in US legal proceedings, despite that it has long been abolished in the country where it originated.

   Just because an illogical grammatical expression has made it into common(*) use--especially, when that is so only for a restricted audience--does not seem reason enough to perpetuate it when there are better, clearer alternatives.

Strange. It seems that it is often the same people who would complain about the use of obscure Perl syntax, that would perpetuate these kinds of in-the-know phrases.

(*)For some definition of the word:common.

A few things.
• The Perl documentation isn't aimed at small children. It's aimed at adult who are assumed to possess some learning ability. Including the ability to learn what a word or phrase means. (If the don't possess that knowledge, they'll struggle to learn any computer language). Perl documentation is peer-to-peer (or peer-to-soon-to-be-peer). A medical text book would use synchronous diaphragmatic flutter instead of "common childhood malady".
• undefined behavior is not archaic, nor obscure. Enough people understand and use it that's idiom in its context.
• If you want to cater for people who would have no idea what "undefined behavior" means, cannot grasp it from the context, and cannot search the web for it, write a patch against perlglossary. That's what it's for.

1. The Perl documentation isn't aimed at small children.

   No. The greater percentage of them will be non-native-English speaking adults without the care-free time & boundless curiosity children have, nor the lack of self-conciousness children exhibit, when they are learning languages.

   Instead, they will have jobs to do, or studies to complete and deadlines to meet. All the social awkwardness, distraction by the illogical, and pre-patterned thinking that means it is 3 to 5 times harder for the average adult to learn a new language than a child.

   What kind of presumptive, jobs-worth, bloody-mindedness does it take to deliberately continue to use an obscure phrase that defies logical analysis and has to be looked up to understand it meaning, when there are other far clearer, logical substitutes?

2. Enough people understand and use it that's idiom in its context.

   The world:1.0; The Western world:0.2; College educated Western world:0.02; CompSci educated:0.001; Native English-speaking:0.00025. It's not so many really.

   It would be really interesting to know where that phrase originates, because despite the "Perl works like C" reference, it does not appear anywhere in K&R.

   Now there is a piece of clear, straightforward plain-English technical writing. They didn't feel the need to tech-it-up with meaningless linguistic constructs; nor mark their membership of the technocrati with shibboleths.

3. If you want to cater for people...

   Yeah! That's kinda the point of a self-help learning site like Perlmonks. Helping people.

   Not baffling them with bs; nor highlighting their difference background or education from ours; nor ...

And I think it was LW himself who set out to make, and continues to want, Perl to be easy to learn.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

This node intentionally left blank

GrandFather shooting blanks

Once you've become a Grandfather that is no longer a disadvantage. ;)

---

True laziness is hard work

"And, if I do X, what is the resulting behavior?"

"We haven't defined that."

"And, if I do X, what is the resulting behavior?"

• Either: "We've specified that it will do Y, so conforming implementations will do that."
• Or "We haven't specified that, so the behavour will be defined by the implementations."

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

We haven't specified that, so the behavour will be defined by the implementations.

That's typically labelled as implementation defined. Which is not the same as undefined behaviour.

This reminds me of the terminology I learned for heart rhythms: regular; regularly irregular; and irregularly irregular. The first is the way a healthy heart beats. The second is unusual but the same in every cycle: a sign of something abnormal but not necessarily incompatible with a long life. And the last is unusual and inconsistent from one cycle to the next: usually very bad.

I wouldn't distinguish between undefined and unspecified myself. I think a definition is just a form of specification.

The phrase "the behavior of a feature" doesn't seem right to me. My reaction is that a feature doesn't have a behavior. Rather, the behavior is a feature. I would be more comfortable with "behavior X is a feature of Perl 6". But this is probably just my problem.

I would say, given the specification of some relevant circumstances, that "the behavior of Perl 6 is undefined" or "unspecified".

If one discovers empirically or by other analysis of an implementation that the behavior is or isn't consistent from trial to trial, this makes the behavior neither more nor less defined or specified. One implementation might behave the same on every repetition and another might behave as randomly as computers are able to. There are endless possibilities, none of which change the specification.

Is there value in specifying that some behavior that is otherwise unspecified is specified to be the same for every repetition with a given implementation but may be arbitrarily different for a different implementation? For one implementation the behavior might be to dump core and for another it might be to launch a missile strike on the demons of the day and for yet another it might be to flip the chirality of the universe - the only thing you can be certain of is that for each implementation, however it behaves, it will behave that way that it does every time - that, at least, is specified and therefore a certainty!! (update: else there's a bug in the implementation). My inclination is that there is not much value in this.

the way in which something functions or operates

• Undefined Behavior
• Undefined behavior in Perl and other languages