| Re: Operator precedence [message #185148 is a reply to message #185143] |
Sun, 02 March 2014 20:22   |
Richard Damon
Messages: 58
Registered: August 2011
Karma:
|
Member |
|
|
On 3/1/14, 2:29 PM, Jerry Stuckle wrote:
> On 3/1/2014 1:39 PM, Richard Damon wrote:
>> On 2/24/14, 11:59 PM, Jerry Stuckle wrote:
>>>
>>> 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.
Which says that INT_MAX must be less than 4,294,967,206 and thus the
program has invoked undefined behavior so ANY output (including no
output) is compliant. This is clearly specified in the standard.
<snip>
>> 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.
>
This is easy.
Rigorous: severely exact or accurate; precise.
Thus to be rigorously defined, a language needs a severely exact or
accurate description of what the language is and what results of every
valid program will be.
For computer languages, this is traditionally done with formal
specifications and grammars. PHP does NOT provide us with one. (It is
hard to prove the non-existence of something, but a determined search of
the site does not reveal one, of course, it would be easy to disprove
this statement by pointing it the location of it).
I will agree that a formal grammar isn't absolutely required for a
rigorous definition, if enough care was taken to FULLY describe every
condition in a less formal manner. This clearly has not happened, as the
statement that caused all this discussion is not CLEARLY spelled out in
the documentation.
Namely, why does the statement
!$a && $a = 42;
bind the $a variable to the = operator even though the && operator has a
higher precedence?
Again, proof of absence is impossible, but a search of the documentation
does not find anything that defines this, further evidenced by that fact
that NO ONE in this thread has offered a statement from the
documentation that clearly indicates that this is how it must work.
THUS, it is proved, PHP is not rigorously defined.
<snip>
>> 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.
>
This is a non-sense statement. The C standard specifically defines the
results, using a specifically defined term, "undefined behavior".
Standards define a form of contract, that if the programmer follows a
few basic requirements, the standard will define what are the expected
results of the program. In C, one of those requirements is that the
program will not generate "undefined behavior". In essence, once a
program performs undefined behavior, the standard washes it hands of
what will result.
<snip>
>>
>> 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.
>
Rigor requires precision, something MUCH harder to do in conversational
language than in something more "precise". Formal grammars tend to be
much easier to be precise, and to verify that you have been complete.
>> 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.
>
See above.
>> 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.
>
As I said, a defect report can be filed for cases where the standard is
in conflict with itself or is unclear or ambiguous. These are errors in
the standard.
A defect report can NOT be filed because the standard says something is
to be done different than it is, or is wanted to be. These are NOT
"Defects" in the standard. A difference in behavior between an
implementation and what the standard requires is ALWAYS a non-conformity
of the implementation, and not an "error" in the standard (assuming it
isn't something in the standard being contradictory, etc).
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]