Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #13041
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Operator precedence |
| Date | 2014-03-01 14:29 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <letcfa$26t$1@dont-email.me> (permalink) |
| References | (5 earlier) <0.914eafe42061d70d7566.20140224044930GMT.87fvn9ru79.fsf@bsb.me.uk> <lefc8a$7ki$1@dont-email.me> <uhUOu.54621$Cd3.33928@en-nntp-07.dc1.easynews.com> <leh7um$vpa$1@dont-email.me> <NPpQu.120042$2V.14562@en-nntp-16.dc1.easynews.com> |
On 3/1/2014 1:39 PM, Richard Damon wrote:
> On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
>> On 2/24/2014 10:41 PM, Richard Damon wrote:
>>> On 2/24/14, 7:00 AM, Jerry Stuckle wrote:
>>>
>>>> What language gives every possible way for you to screw up your
>>>> programming?
>>>>
>>>> If you want to find out how some screwed-up code works in ANY language,
>>>> you try it and find out.
>>>>
>>>
>>> Herein lies the path to madness.
>>>
>>> Take the following C code
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>> int i = 4;
>>> i = ++i + i++;
>>> printf("%i\n", i);
>>> return 0;
>>> }
>>>
>>> Question, you want to find out what this is supposed to do. By your
>>> statement, you run it on a system. The problem is that the answer you
>>> get is only valid for THAT system, and possible for that EXACT piece of
>>> code.
>>>
>>
>> No, it shows how it works with THIS compiler. Not even this system - a
>> different compiler may give different results. But then the same is
>> true for ANY compiler.
>>
>> But then all I claimed was to try it and see how it works for THIS system.
>>
>> For instance, what is the output of:
>>
>> int main() {
>> int i = 1;
>> int j = i << 32;
>> printf("%d\n", j);
>> ?>
>>
>
> The C language spec makes this clear.
>
> The result of 1 << 32 will be 4,294,967,206.
> Now, if INT_MAX is defined to be a smaller value, then the program has
> performed "undefined behavior", and the standard provides no constraints
> on what happens after that point.
>
In my compiler, the output is 0. And it is ANSI compliant.
> In common terms, if int is a type of at least 34 bits, (to include the
> sign bit), this program has defined behavior, and the standard defines
> its operation. if int is only a 33 bit type (or smaller), then the
> compiler is not obligated to make this work. Practically, you are apt to
> get either the result 0 or 1, (0 if the machine actually does the
> shifting, 1 if the machine ignores extra shift count bits), but anything
> is allowed.
>
This has nothing to do with the subject - which is the size of an int.
>>> The REAL answer is you compare the code to the formal specification of
>>> the language, and you get the answer.
>>>
>>
>> IF you have the formal specification available, and are able to
>> understand it.
>>
>
> Not understanding the formal specification is a programmer issue. A
> formal language CAN be used without access (or understanding) of the
> formal specification through other documentation, and in fact, most
> programmers can do a lot without needing to refer to the formal
> specifications. The mere existence of them provides a "higher court" to
> take issue that seem to come up, and figure out if the documentation or
> the implementation has a problem when something doesn't seem right.
>
Yes, but when you're dealing with courseware, knowledge and
understanding of the specification is a very good idea.
>>> Too many people use your answer, and then complain because they get a
>>> different answer on another machine, or in different circumstances, and
>>> then complain that the compiler is "broken", when the real answer is
>>> that THEIR program was the one that was broken.
>>>
>>> (For those not familiar with C, the answer in this case is that the
>>> program has performed "undefined behavior" by modifying i twice without
>>> a sequence point, and thus *ANY* resultant behavior is acceptable.
>>>
>>
>> That is true - and you will not find your example in the ANSI C spec -
>> which is why its output is not defined.
>>
>
>
>>> Here is a question, does PHP's documentation promise how the equivalent
>>> PHP statement will execute?
>>>
>>> ...
>>
>> You tell me.
>>
>
> YOU made the claim that PHP is rigorously defined. Person making
> assertion tends to have burden of proof. Lack of definition would be an
> indication that it is NOT so rigorously defined.
>
YOU made the first assertion - that PHP is NOT rigorously defined. So,
according to your "rules", you have to prove it - which you have not.
>>>
>>>
>>>>> The assignment operators in PHP have, in effect, different precedences
>>>>> on the left and the right (a feature that some languages flaunt) but
>>>>> that is not common and certainly not part of what I'd call basic
>>>>> knowledge. The documentation gives one example of this peculiarity,
>>>>> but
>>>>> that does not clear the matter up conclusively. For example, in some
>>>>> languages permit assignment to the result of a conditional expression,
>>>>> but I think it's hard to tell from the documentation what these two do:
>>>>>
>>>>> $bool ? $a : $b = 42;
>>>>> ($bool ? $a : $b) = 42;
>>>>>
>>>>
>>>> Show me what language provides you with examples of every possible
>>>> combination of operators and expressions.
>>>
>>> Read the C Grammer definition. It precisely describes how ANY expression
>>> is to be parsed.
>>>
>>> It does give the compiler freedom to choose the order to execute the
>>> parse tree, so things without inherent order have no promise of order,
>>> but this is made explicit.
>>>
>>
>> I have - many times while working on updating C courses. So much, in
>> fact, that I completely wore out the ANSI spec I had (and which cost me
>> a bunch of $$$).
>>
>> The spec specifies the order that operators are evaluated. It does NOT
>> specify the order in which operands are evaluated. That is why your
>> example has undefined results - the spec does not define what should
>> happen.
>>
>
> Actually, the specification DOES say what happens, the program has
> invoked undefined behavior, and any further actions are beyond the scope
> of the standard. This IS a precise statement, it may not be real useful
> to the programmer figure out predict what will happen, but it does
> provide "rules of engagement" for writing programs. The programmer
> promises to make sure the code doesn't invoke undefined behavior, and
> the standard(s) will define what the program does.
>
Actually, no, the specification does not say specifically what happens
in a case such as j = i++ + ++i; That is why the operation is
"undefined" - because nothing in the spec defines what should happen.
>>>
>>>>
>>>>> The operator precedence table suggests that both mean the same thing,
>>>>> but they don't. I don't think the meaning of either is easily
>>>>> determined from the documentation.
>>>>>
>>>>> <snip>
>>>>>
>>>>
>>>> So you try it out, as you do in any language. But just because you can
>>>> come up with some weird combination of operators which isn't listed in
>>>> the doc does not mean the language is not rigorously defined.
>>>> with
>>>> But it does mean you are trolling.
>>>>
>>>
>>> Rigorously defined would mean "precisely or exactly defined", which,
>>> yes, does say that if you can come up with a "weird" combination, that
>>> is not documented as to what is to happen, the definition is not
>>> rigorous. A Formal definition, will be complete, as that is part of
>>> being formal.
>>>
>>
>> PHP is defined as rigorously as other languages. Just in a more
>> reader-friendly way. (It took me a long time to figure out my way
>> through the ANSI C spec - and even longer for SQL).
>>
>> But then since you seem to hate PHP so much, I suggest you just find
>> another language more to your liking and stop wasting people's time in a
>> PHP newsgroup. More trolls we don't need.
>>
>
> I don't hate PHP, in fact I find it a very useful language for many usages.
>
> IF you want to claim that PHP is as rigorously defined as a language
> like C, then perhaps your problem is you don't understand what rigorous
> really means, and where it is useful in defining things.
>
I understand exactly what rigorous means. But you obviously think it
means "in arcane and hard to understand language". It does not.
> PHP is NOT "rigorously" defined, its documentation is predominately
> "natural language" based, not on formal grammar. This does have
> advantages for the "common" programmer, making it easier to learn the
> basics of the language, but does leave some minor details, which aren't
> normally important poorly defined. Since PHP is predominately a "single
> implementation language", it can get away with this.
>
And how does the language used make it not "rigorously defined". Prove
your statement - according to your rules.
> One other effect of this is that in PHP, it is possible to file a
> "documentation bug" for the documentation differing from how the
> compiler operates. (this might result in a documentation change, or it
> might be determined that it really is a program bug). With a formal
> language, the only "bugs" that could be filed against the standard would
> be a case where the documentation was in conflict with itself, otherwise
> and discrepancy between the documentation and an implementation is, by
> definition, a non-conformity in the implementation.
>
It's also possible to file a "documentation bug" with ANSI
documentation, also. It's handled differently, but ANSI understands
that even its documentation can have errors.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 18:03 +0100
Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-23 19:42 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 21:23 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 16:34 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-23 18:36 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 21:09 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 04:49 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:56 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 17:38 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:25 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 00:38 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:07 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 01:37 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 02:12 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 03:29 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:41 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 19:55 +0100
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 21:36 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 03:08 +0000
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 04:17 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:45 +0000
Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-25 21:45 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 07:00 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 18:11 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 14:27 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:25 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 20:40 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:23 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 16:45 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:32 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:47 -0500
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 16:56 +0000
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 13:59 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 20:19 +0100
Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:43 +0100
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:02 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:01 -0500
Object constructors/destructors (was: Operator precedence) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:19 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:32 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:55 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 17:01 -0500
Re: Object constructors/destructors Adam Harvey <usenet@adamharvey.name> - 2014-02-25 23:22 +0000
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:10 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 21:10 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 16:01 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 22:59 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 17:19 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 23:39 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:30 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-27 18:28 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:09 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 14:52 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 09:08 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 16:52 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 11:03 -0500
Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 01:00 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:39 -0500
Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 18:29 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:14 -0500
Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 00:18 +0100
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:08 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 07:50 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 08:44 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 23:49 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 08:25 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-01 12:56 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:22 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 14:28 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:42 -0500
Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 17:14 -0500
Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 17:48 -0500
Re: Object constructors/destructors Tim Streater <timstreater@greenbee.net> - 2014-03-02 23:05 +0000
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 21:08 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:29 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 23:15 +0000
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-24 22:41 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:59 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-01 13:39 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:29 -0500
Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-02 15:22 -0500
Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:49 -0500
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:15 +0100
Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-23 20:56 +0000
Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 14:28 +0100
csiph-web