| Re: Operator precedence [message #185150 is a reply to message #185148] |
Sun, 02 March 2014 20:49   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 3/2/2014 3:22 PM, Richard Damon wrote:
> 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.
>
Then you can't say that PHP is not rigorously defined.
> 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.
>
There are many undefined operations and expressions in other languages
such as C, C++ and java, also. The spec only needs to define what CAN
be done - not what CANNOT be done.
If you think there is an error in the documentation, then file a bug
report against the doc.
> <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 what CAN be done, not what CANNOT be done. If you
follow the spec as to what CAN be done, then the behavior of your
program is defined. If you do not follow the spec, then the behavior of
your program is undefined.
> 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>
>
Exactly. You do not use expressions which are not defined by the spec.
>>>
>>> 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.
>
Which does not mean it cannot be done. A spec does not need to be hard
to read to be rigorous.
>>> 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.
>
You have not proven anything. All you say is that since the PHP spec is
easy to read, PHP is not rigorously defined. I happen to disagree with
that statement.
If you follow the doc, your program will behave as expected. If you
think there is an error in the doc, then you need to file a bug report.
>>> 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).
>
>
I did not say you can file a defect because the standard says something
is to be done different than it is. However, since ZEND is in charge of
the doc and the language, you can file a bug report - and they will
decide whether the language or the doc is wrong.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]