| Re: Operator precedence [message #185141 is a reply to message #185056] |
Sat, 01 March 2014 18:39   |
Richard Damon
Messages: 58
Registered: August 2011
Karma:
|
Member |
|
|
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 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.
>> 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.
>> 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.
>>
>>
>>>> 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.
>>
>>>
>>>> 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.
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.
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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]