Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #12889 > unrolled thread
| Started by | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| First post | 2014-02-23 18:03 +0100 |
| Last post | 2014-02-24 14:28 +0100 |
| Articles | 4 on this page of 84 — 8 participants |
Back to article view | Back to comp.lang.php
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
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-03-02 15:49 -0500 |
| Message-ID | <lf05gh$vd4$1@dont-email.me> |
| In reply to | #13045 |
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@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-25 19:15 +0100 |
| Message-ID | <530cddb0$0$9507$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12950 |
Richard Damon wrote:
> 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.
>
> The REAL answer is you compare the code to the formal specification of
> the language, and you get the answer.
>
> 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.
>
> Here is a question, does PHP's documentation promise how the equivalent
> PHP statement will execute?
AFAIK, no. There was a bug report a while ago regarding this issue[1],
followed by a discussion on the PHP internals mailing list[2].
Apparently, the example that would have clarified that the behavior is
undefined or defined in a particular way, is not available in the
operator precedence documentation.
[1] <https://bugs.php.net/bug.php?id=65087>
[2] <http://news.php.net/php.internals/68229>
--
Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-02-23 20:56 +0000 |
| Message-ID | <0.c80cc8315f52ea72d0ef.20140223205620GMT.87bnxxtuob.fsf@bsb.me.uk> |
| In reply to | #12889 |
Christoph Michael Becker <cmbecker69@arcor.de> writes:
> I've stumbled upon the following code:
>
> !$a && $a = 42;
>
> Apparently, this is meant instead of
>
> if (!$a) $a = 42;
>
> or
>
> !$a AND $a = 42;
>
> However, I am quite confused that it works because the = operator has
> lower precendence than the && operator[1]. Actually that should mean
> the statement is equivalent to
>
> (!$a && $a) = 42;
>
> But this obviously won't work.
The precedence table is wrong -- or at least something of a
simplification. The grammar for PHP (for which I had to resort to the
source code) does not reflect that table for the = operator. The
grammar has explicit rules for = that result in the precedence being
ignored in this particular case.
The precedence comes into play when the YACC (or Bison or whatever)
source says something like
exp: ...
| exp '=' exp
| ...
but instead is says:
exp: ...
| variable = exp
(this is a somewhat abbreviated explanation) so there can never be a
full expression on the left hand side. Note that this works:
$a + $a = 42;
and parses like
$a + ($a = 42);
There is nothing special about && in this respect. The precedence does
count in some situations. For example, compare
$a = true && $b = false; // $a = (true && ($b = false));
and
$a = true and $b = false; // ($a = true) and ($b = false);
> Why does the mentioned statement has the "expected" result? Is it
> reliable to write it that way?
Interesting question. I don't know where the language is defined.
Maybe one day the source code will reflect the documentation of vice
versa. Maybe one day both will match some other, external,
specification.
> [1] <http://www.php.net/manual/en/language.operators.precedence.php>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Christoph Michael Becker <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-02-24 14:28 +0100 |
| Message-ID | <530b48e6$0$9521$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #12903 |
Ben Bacarisse wrote: > Christoph Michael Becker <cmbecker69@arcor.de> writes: > >> I've stumbled upon the following code: >> >> !$a && $a = 42; >> >> Apparently, this is meant instead of >> >> if (!$a) $a = 42; >> >> or >> >> !$a AND $a = 42; >> >> However, I am quite confused that it works because the = operator has >> lower precendence than the && operator[1]. Actually that should mean >> the statement is equivalent to >> >> (!$a && $a) = 42; >> >> But this obviously won't work. > > The precedence table is wrong -- or at least something of a > simplification. The grammar for PHP (for which I had to resort to the > source code) does not reflect that table for the = operator. The > grammar has explicit rules for = that result in the precedence being > ignored in this particular case. > > The precedence comes into play when the YACC (or Bison or whatever) > source says something like > > exp: ... > | exp '=' exp > | ... > > but instead is says: > > exp: ... > | variable = exp > > (this is a somewhat abbreviated explanation) so there can never be a > full expression on the left hand side. Note that this works: > > $a + $a = 42; > > and parses like > > $a + ($a = 42); > > There is nothing special about && in this respect. The precedence does > count in some situations. For example, compare > > $a = true && $b = false; // $a = (true && ($b = false)); > > and > > $a = true and $b = false; // ($a = true) and ($b = false); Thanks for your investigations and explanations which confirm my later findings. >> Why does the mentioned statement has the "expected" result? Is it >> reliable to write it that way? > > Interesting question. I don't know where the language is defined. > Maybe one day the source code will reflect the documentation of vice > versa. Maybe one day both will match some other, external, > specification. Indeed, it seems that a formal syntax *specification* is missing, especially because the expression grammar has striking similarities with C and C derivates, but obviously some important and IMHO unintuitive differences. At least for now it seems prudent to avoid such edge-cases and to add parentheses around assignment operations which are part of more complex expressions. >> [1] <http://www.php.net/manual/en/language.operators.precedence.php> -- Christoph M. Becker
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.php
csiph-web