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.
Why does the mentioned statement has the "expected" result? Is it
reliable to write it that way?
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-23T17:03:50-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=184996&th=123426#msg_184996
cmbecker69@arcor.de> wrote:
> 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.
>
> Why does the mentioned statement has the "expected" result? Is it
> reliable to write it that way?
>
> [1] <http://www.php.net/manual/en/language.operators.precedence.php>
>
This shows one of the major problems with PHP: there is no formal language
definition, you have to go by examples in the help file to intuit what is
or is not valid. Where is the BNF definition of the language? There is none
AFAICT.
Under "Control structures" the PHP help file says "Any PHP script is built
out of a series of statements" but offers no definition of what constitutes
a statement. Under "Expressions" the manual says "Expressions are the most
important building stones of PHP. In PHP, almost anything you write is an
expression." How do we square that with the previous claim? In the end I
think you should avoid using PHP for anything critical since it is a
language defined by handwaving, where you can't formally determine the
meaning of a construct, yuo either have to try it out or find an analogous
example in the help file.
In your example, the answer to why the construction works is given in a
footnote to the section "Operator Precedence" which states
"Note: Although = has a lower precedence than most other operators, PHP
will still allow expressions similar to the following: if (!$a = foo()), in
which case the return value of foo() is put into $a. "
The formal meaning of this footnote is "BOOGA BOOGA!"
This kind of thing give me the heeby jeebies and makes me think I should be
using some other language for server side scripting (maybe perl is better
defined?)]]>GS2014-02-23T19:42:32-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=184999&th=123426#msg_184999
> Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>
>> 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.
>>
>> Why does the mentioned statement has the "expected" result? Is it
>> reliable to write it that way?
>>
>> [1] <http://www.php.net/manual/en/language.operators.precedence.php>
>>
>
> This shows one of the major problems with PHP: there is no formal language
> definition, you have to go by examples in the help file to intuit what is
> or is not valid. Where is the BNF definition of the language? There is none
> AFAICT.
Indeed, I have not yet found a formal BNF specification in the PHP
manual, too. However, in the PHP sources there is the bison file
Zend/zend_language_parser.y, which might be regarded as syntax
specification.
> Under "Control structures" the PHP help file says "Any PHP script is built
> out of a series of statements" but offers no definition of what constitutes
> a statement. Under "Expressions" the manual says "Expressions are the most
> important building stones of PHP. In PHP, almost anything you write is an
> expression." How do we square that with the previous claim? In the end I
> think you should avoid using PHP for anything critical since it is a
> language defined by handwaving, where you can't formally determine the
> meaning of a construct, yuo either have to try it out or find an analogous
> example in the help file.
>
> In your example, the answer to why the construction works is given in a
> footnote to the section "Operator Precedence" which states
Thanks for pointing this out.
> "Note: Although = has a lower precedence than most other operators, PHP
> will still allow expressions similar to the following: if (!$a = foo()), in
> which case the return value of foo() is put into $a. "
>
> The formal meaning of this footnote is "BOOGA BOOGA!"
Um, well, yes.
From looking at the mentioned bison file the meaning of the note is
becoming clearer. Roughly summarized, expressions are not defined
"symmetrically", as for instance, in C, but somewhat "pragmatically".
The statement given above is parsed the following way (simplified):
That explains why it works as described. However, I somewhat wonder why
there are two sets of boolean operators (&& and || vs. AND and OR). It
seems to me they are only different wrt. the ternary operator, but in
this case using parentheses seems to be preferable, anyway.
> This kind of thing give me the heeby jeebies and makes me think I should be
> using some other language for server side scripting (maybe perl is better
> defined?)
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-23T20:23:47-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185005&th=123426#msg_185005
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 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.
--
Ben.]]>Ben Bacarisse2014-02-23T20:56:20-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185008&th=123426#msg_185008
> Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>
>> 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.
>>
>> Why does the mentioned statement has the "expected" result? Is it
>> reliable to write it that way?
>>
>> [1] <http://www.php.net/manual/en/language.operators.precedence.php>
>>
>
> This shows one of the major problems with PHP: there is no formal language
> definition, you have to go by examples in the help file to intuit what is
> or is not valid. Where is the BNF definition of the language? There is none
> AFAICT.
>
Incorrect. There is a formal definition, as indicated in the doc at
www.php.net.
> Under "Control structures" the PHP help file says "Any PHP script is built
> out of a series of statements" but offers no definition of what constitutes
> a statement. Under "Expressions" the manual says "Expressions are the most
> important building stones of PHP. In PHP, almost anything you write is an
> expression." How do we square that with the previous claim? In the end I
> think you should avoid using PHP for anything critical since it is a
> language defined by handwaving, where you can't formally determine the
> meaning of a construct, yuo either have to try it out or find an analogous
> example in the help file.
>
Yes, and both "statements" and "expressions" have had specific
definitions when it comes to computer programming for at least 50 years.
It is no different in PHP.
They are correct. Almost anything is an expression. A statement is one
or more expressions terminated by a ';'.
PHP is a well-defined language very suitable for critical work. Just
because you don't understand it does not mean it's a poor language. It
means you need to broaden your understanding of word definitions.
> In your example, the answer to why the construction works is given in a
> footnote to the section "Operator Precedence" which states
>
> "Note: Although = has a lower precedence than most other operators, PHP
> will still allow expressions similar to the following: if (!$a = foo()), in
> which case the return value of foo() is put into $a. "
>
Yes, a side effect in the language.
> The formal meaning of this footnote is "BOOGA BOOGA!"
>
The formal meaning of your statement is "bull shite".
> This kind of thing give me the heeby jeebies and makes me think I should be
> using some other language for server side scripting (maybe perl is better
> defined?)
>
Good. Please use some other language then. We have enough idiots using
PHP as it is.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-23T21:34:28-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185013&th=123426#msg_185013
> On 2/23/2014 2:42 PM, GS wrote:
>> This shows one of the major problems with PHP: there is no formal
>> language
>> definition, you have to go by examples in the help file to intuit what is
>> or is not valid. Where is the BNF definition of the language? There is
>> none
>> AFAICT.
>>
>
> Incorrect. There is a formal definition, as indicated in the doc at
> www.php.net.
>
Do you have a pointer to where "expression" is precisely defined (other
than reading code).
A statement in the documentation says:
PHP provides a full and powerful implementation of expressions, and
documenting it entirely goes beyond the scope of this manual.
Note that this is the "Language Reference" under "Expressions", if that
isn't the right spot to formally define the term (or at least place a
pointer to the formal definition), I am not sure what would be.
This shows that PHP is not a "formally defined language".
That doesn't mean it isn't powerful, or useful, or the right tool to use
in some places, but does say that it lacks some formal rigor.
The lack of formal rigor says that there are some questions which just
can't be answered by reading the language documentation.
The original question was a good example of this. the assignment
operator is described as having a precedence (fairly low) just like all
other operators, with some vague comments that it is done in a way that
certain things just work. In comments on looking at the code, the left
operand of assignment is a variable, and not an expression, effectively
giving assignment a very high precedence to the left, and a very low
precedence to the right (if the grammar even does end up being actually
describable precisely with precedence). To my knowledge, this detail is
NOT formally presented in the documentation.
This is somewhat the result of the type of language PHP is. PHP is
inherently a "single source" language, there is one implementation, and
that ultimately is the definition of what the language is (for that
version). This is as opposed to a language like C, where there is a
formal spec for the language, and many people can write their own
implementation, and that implementation can be judged by if it fully
meets the specification or not.
I am NOT proposing the PHP should stop and go to the effort to build a
standard of the level of C and the like, it isn't used as that type of
language. It might not hurt to "back-port" some of the details of
grammar as parsed, into an appendix.]]>Richard Damon2014-02-23T23:36:18-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185014&th=123426#msg_185014
> On 2/23/14, 4:34 PM, Jerry Stuckle wrote:
>> On 2/23/2014 2:42 PM, GS wrote:
>>> This shows one of the major problems with PHP: there is no formal
>>> language
>>> definition, you have to go by examples in the help file to intuit what is
>>> or is not valid. Where is the BNF definition of the language? There is
>>> none
>>> AFAICT.
>>>
>>
>> Incorrect. There is a formal definition, as indicated in the doc at
>> www.php.net.
>>
> Do you have a pointer to where "expression" is precisely defined (other
> than reading code).
>
Try any Introduction to Programming book. Documentation (not just PHP)
does not normally define commonly used terms.
Do you expect it to define terms such as "program", "web", and such, also?
"Expression" is used in almost every programming language around.
> A statement in the documentation says:
>
> PHP provides a full and powerful implementation of expressions, and
> documenting it entirely goes beyond the scope of this manual.
>
That is correct.
> Note that this is the "Language Reference" under "Expressions", if that
> isn't the right spot to formally define the term (or at least place a
> pointer to the formal definition), I am not sure what would be.
>
> This shows that PHP is not a "formally defined language".
>
According to you, the documentation should also define "Language",
"full", "Powerful", "Implementation"...
> That doesn't mean it isn't powerful, or useful, or the right tool to use
> in some places, but does say that it lacks some formal rigor.
>
Once again, incorrect.
> The lack of formal rigor says that there are some questions which just
> can't be answered by reading the language documentation.
>
It can if you have a basic understanding of programming.
> The original question was a good example of this. the assignment
> operator is described as having a precedence (fairly low) just like all
> other operators, with some vague comments that it is done in a way that
> certain things just work. In comments on looking at the code, the left
> operand of assignment is a variable, and not an expression, effectively
> giving assignment a very high precedence to the left, and a very low
> precedence to the right (if the grammar even does end up being actually
> describable precisely with precedence). To my knowledge, this detail is
> NOT formally presented in the documentation.
>
No, the original question shows a basic lack of knowledge of terms used
in programming. As does your argument.
> This is somewhat the result of the type of language PHP is. PHP is
> inherently a "single source" language, there is one implementation, and
> that ultimately is the definition of what the language is (for that
> version). This is as opposed to a language like C, where there is a
> formal spec for the language, and many people can write their own
> implementation, and that implementation can be judged by if it fully
> meets the specification or not.
>
It has NOTHING to do with PHP being a "single source" language. It has
EVERYTHING to do with your lack of knowledge of basic programming terms.
> I am NOT proposing the PHP should stop and go to the effort to build a
> standard of the level of C and the like, it isn't used as that type of
> language. It might not hurt to "back-port" some of the details of
> grammar as parsed, into an appendix.
>
PHP is well documented with a formal rigor, as indicated in the manual.
Your lack of knowledge is not PHP's problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-24T02:09:16-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185015&th=123426#msg_185015
jstucklex@attglobal.net> writes:
> On 2/23/2014 6:36 PM, Richard Damon wrote:
>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote:
>>> On 2/23/2014 2:42 PM, GS wrote:
>>>> This shows one of the major problems with PHP: there is no formal
>>>> language
>>>> definition, you have to go by examples in the help file to intuit what is
>>>> or is not valid. Where is the BNF definition of the language? There is
>>>> none
>>>> AFAICT.
>>>>
>>> Incorrect. There is a formal definition, as indicated in the doc at
>>> www.php.net.
>>>
>> Do you have a pointer to where "expression" is precisely defined (other
>> than reading code).
>
> Try any Introduction to Programming book. Documentation (not just
> PHP) does not normally define commonly used terms.
I don't think it's that clear cut. Expressions are built from
operators, but is ',' an operator in PHP? It appears in the operator
precedence table but it isn't an operator in an sense that would
normally be understood by someone familiar with these terms.
<snip>
>> That doesn't mean it isn't powerful, or useful, or the right tool to use
>> in some places, but does say that it lacks some formal rigor.
>
> Once again, incorrect.
>
>> The lack of formal rigor says that there are some questions which just
>> can't be answered by reading the language documentation.
>
> It can if you have a basic understanding of programming.
Again, I don't think it's that simple. How would you determine if the
following program is permitted and, if it is, what it does?
if (false) label: else echo "else\n";
goto label;
You could try it, of course, but that's hardly very formal.
>> The original question was a good example of this. the assignment
>> operator is described as having a precedence (fairly low) just like all
>> other operators, with some vague comments that it is done in a way that
>> certain things just work. In comments on looking at the code, the left
>> operand of assignment is a variable, and not an expression, effectively
>> giving assignment a very high precedence to the left, and a very low
>> precedence to the right (if the grammar even does end up being actually
>> describable precisely with precedence). To my knowledge, this detail is
>> NOT formally presented in the documentation.
>
> No, the original question shows a basic lack of knowledge of terms
> used in programming. As does your argument.
This puzzles me. What basic knowledge would have cleared up the
original question?
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;
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>
--
Ben.]]>Ben Bacarisse2014-02-24T04:49:30-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185016&th=123426#msg_185016
> […] Expressions are built from operators, but is ',' an operator in PHP?
> It appears in the operator precedence table but it isn't an operator in an
> sense that would normally be understood by someone familiar with these
> terms.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann]]>Thomas 'PointedEars' 2014-02-24T11:56:46-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185017&th=123426#msg_185017
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote:
>>>> On 2/23/2014 2:42 PM, GS wrote:
>>>> > This shows one of the major problems with PHP: there is no formal
>>>> > language
>>>> > definition, you have to go by examples in the help file to intuit what is
>>>> > or is not valid. Where is the BNF definition of the language? There is
>>>> > none
>>>> > AFAICT.
>>>> >
>>>> Incorrect. There is a formal definition, as indicated in the doc at
>>>> www.php.net.
>>>>
>>> Do you have a pointer to where "expression" is precisely defined (other
>>> than reading code).
>>
>> Try any Introduction to Programming book. Documentation (not just
>> PHP) does not normally define commonly used terms.
>
> I don't think it's that clear cut. Expressions are built from
> operators, but is ',' an operator in PHP? It appears in the operator
> precedence table but it isn't an operator in an sense that would
> normally be understood by someone familiar with these terms.
>
It is an operator, as indicated by its appearance in the table of
operators. Operators are not limited to +-*/.
> <snip>
>>> That doesn't mean it isn't powerful, or useful, or the right tool to use
>>> in some places, but does say that it lacks some formal rigor.
>>
>> Once again, incorrect.
>>
>>> The lack of formal rigor says that there are some questions which just
>>> can't be answered by reading the language documentation.
>>
>> It can if you have a basic understanding of programming.
>
> Again, I don't think it's that simple. How would you determine if the
> following program is permitted and, if it is, what it does?
>
> if (false) label: else echo "else\n";
> goto label;
>
> You could try it, of course, but that's hardly very formal.
>
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.
>>> The original question was a good example of this. the assignment
>>> operator is described as having a precedence (fairly low) just like all
>>> other operators, with some vague comments that it is done in a way that
>>> certain things just work. In comments on looking at the code, the left
>>> operand of assignment is a variable, and not an expression, effectively
>>> giving assignment a very high precedence to the left, and a very low
>>> precedence to the right (if the grammar even does end up being actually
>>> describable precisely with precedence). To my knowledge, this detail is
>>> NOT formally presented in the documentation.
>>
>> No, the original question shows a basic lack of knowledge of terms
>> used in programming. As does your argument.
>
> This puzzles me. What basic knowledge would have cleared up the
> original question?
>
The definition of "expression". It's something covered in our
"Introduction to Programming" course - which does not cover any
language, only the basic process.
> 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.
> 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.
But it does mean you are trolling.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-24T12:00:09-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185018&th=123426#msg_185018
> 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.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-24T13:28:07-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185021&th=123426#msg_185021
> Ben Bacarisse wrote:
>
>> […] Expressions are built from operators, but is ',' an operator in PHP?
>> It appears in the operator precedence table but it isn't an operator in an
>> sense that would normally be understood by someone familiar with these
>> terms.
>
> ECMAScript has a “Comma Operator”, too.
>
> <http://ecma-international.org/ecma-262/5.1/#sec-11.14>
However, PHP's "comma operator" seems to be more powerful, as accoding
to the manual[1] it has "many uses". ;) SCNR.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-24T16:38:43-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185022&th=123426#msg_185022
> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> The original question was a good example of this. the assignment
>>>> operator is described as having a precedence (fairly low) just like all
>>>> other operators, with some vague comments that it is done in a way that
>>>> certain things just work. In comments on looking at the code, the left
>>>> operand of assignment is a variable, and not an expression, effectively
>>>> giving assignment a very high precedence to the left, and a very low
>>>> precedence to the right (if the grammar even does end up being actually
>>>> describable precisely with precedence). To my knowledge, this detail is
>>>> NOT formally presented in the documentation.
>>>
>>> No, the original question shows a basic lack of knowledge of terms
>>> used in programming. As does your argument.
>>
>> This puzzles me. What basic knowledge would have cleared up the
>> original question?
>>
>
> The definition of "expression". It's something covered in our
> "Introduction to Programming" course - which does not cover any
> language, only the basic process.
Would you mind stating your definition of "expression" here?
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-24T17:11:21-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185025&th=123426#msg_185025
> Jerry Stuckle wrote:
>
>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> > The original question was a good example of this. the assignment
>>>> > operator is described as having a precedence (fairly low) just like all
>>>> > other operators, with some vague comments that it is done in a way that
>>>> > certain things just work. In comments on looking at the code, the left
>>>> > operand of assignment is a variable, and not an expression, effectively
>>>> > giving assignment a very high precedence to the left, and a very low
>>>> > precedence to the right (if the grammar even does end up being actually
>>>> > describable precisely with precedence). To my knowledge, this detail is
>>>> > NOT formally presented in the documentation.
>>>>
>>>> No, the original question shows a basic lack of knowledge of terms
>>>> used in programming. As does your argument.
>>>
>>> This puzzles me. What basic knowledge would have cleared up the
>>> original question?
>>>
>>
>> The definition of "expression". It's something covered in our
>> "Introduction to Programming" course - which does not cover any
>> language, only the basic process.
>
> Would you mind stating your definition of "expression" here?
>
I don't think you want MY definition. That will just cause another
argument. Why don't you look up the common definition of "expression"?
I'm sure you know how to use Google.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-24T19:27:29-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185028&th=123426#msg_185028
jstucklex@attglobal.net> writes:
> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> On 2/23/14, 4:34 PM, Jerry Stuckle wrote:
>>>> > On 2/23/2014 2:42 PM, GS wrote:
>>>> >> This shows one of the major problems with PHP: there is no formal
>>>> >> language
>>>> >> definition, you have to go by examples in the help file to intuit what is
>>>> >> or is not valid. Where is the BNF definition of the language? There is
>>>> >> none
>>>> >> AFAICT.
>>>> >>
>>>> > Incorrect. There is a formal definition, as indicated in the doc at
>>>> > www.php.net.
>>>> >
>>>> Do you have a pointer to where "expression" is precisely defined (other
>>>> than reading code).
>>>
>>> Try any Introduction to Programming book. Documentation (not just
>>> PHP) does not normally define commonly used terms.
>>
>> I don't think it's that clear cut. Expressions are built from
>> operators, but is ',' an operator in PHP? It appears in the operator
>> precedence table but it isn't an operator in an sense that would
>> normally be understood by someone familiar with these terms.
>
> It is an operator, as indicated by its appearance in the table of
> operators. Operators are not limited to +-*/.
I am familiar with languages that have a ',' operator, which is why I
brought it up. Normally, combining expressions with an operator makes a
new expression, but that's not true in PHP for the comma. For example,
f() and g() are expressions, but (f(), g()) is not. That's why,
presumably, there is no description of what it does in the section on
operators -- it isn't one!
<snip>
>>>> The lack of formal rigor says that there are some questions which just
>>>> can't be answered by reading the language documentation.
>>>
>>> It can if you have a basic understanding of programming.
>>
>> Again, I don't think it's that simple. How would you determine if the
>> following program is permitted and, if it is, what it does?
>>
>> if (false) label: else echo "else\n";
>> goto label;
>>
>> You could try it, of course, but that's hardly very formal.
>
> What language gives every possible way for you to screw up your
> programming?
You seemed to be disagreeing with the statement that there are some
questions which just can't be answered by reading the language
documentation. All I was doing was giving an example of a question I
could not answer from the documentation.
I agree it's very much a corner case (and many not worth an answer) but
there are other such questions. For example, from the documentation
alone I can't explain why ($i++, $j++) is not a valid expression, given
that it appears to consist of brackets and operators and variables, all
put together in the usual way.
> If you want to find out how some screwed-up code works in ANY
> language, you try it and find out.
That's a flawed method. If I have an algorithm that shifts bits about,
but sometimes shifts them *all* out, how can I be sure what
1 << PHP_INT_SIZE*8
really does? If I test it, and it does what I want, can I be sure that
on some other hardware it will do the same? Does PHP define the
meaning of this expression, or does it leave it open (and possibly up to
what the hardware does)?
<snip>
>> 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.
I never suggested otherwise. However, in more rigorously defined
languages you can find out what combinations are permitted from the
specification. With PHP, I often end up just trying things because I
can't find the answer in the documentation. I then assume that what
happens now is what will always happen -- i.e. that the reference
implementation is the specification.
>> 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.
I think that's exactly what it means.
> But it does mean you are trolling.
Eh? This whole thread is an interesting technical discussion about the
degree to which PHP programs are well-defined. If you really think my
contributions are trolling, you know the well-worn advice: don't feed
me.
> Ben Bacarisse wrote:
>
>> […] Expressions are built from operators, but is ',' an operator in PHP?
>> It appears in the operator precedence table but it isn't an operator in an
>> sense that would normally be understood by someone familiar with these
>> terms.
>
> ECMAScript has a “Comma Operator”, too.
But my point was the PHP doesn't have one -- not in any normal sense of
the word. ECMAScript really does have one (like C and C++ do).
<snip>
--
Ben.]]>Ben Bacarisse2014-02-24T21:25:51-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185030&th=123426#msg_185030
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> > On 2/23/14, 4:34 PM, Jerry Stuckle wrote:
>>>> >> On 2/23/2014 2:42 PM, GS wrote:
>>>> >>> This shows one of the major problems with PHP: there is no formal
>>>> >>> language
>>>> >>> definition, you have to go by examples in the help file to intuit what is
>>>> >>> or is not valid. Where is the BNF definition of the language? There is
>>>> >>> none
>>>> >>> AFAICT.
>>>> >>>
>>>> >> Incorrect. There is a formal definition, as indicated in the doc at
>>>> >> www.php.net.
>>>> >>
>>>> > Do you have a pointer to where "expression" is precisely defined (other
>>>> > than reading code).
>>>>
>>>> Try any Introduction to Programming book. Documentation (not just
>>>> PHP) does not normally define commonly used terms.
>>>
>>> I don't think it's that clear cut. Expressions are built from
>>> operators, but is ',' an operator in PHP? It appears in the operator
>>> precedence table but it isn't an operator in an sense that would
>>> normally be understood by someone familiar with these terms.
>>
>> It is an operator, as indicated by its appearance in the table of
>> operators. Operators are not limited to +-*/.
>
> I am familiar with languages that have a ',' operator, which is why I
> brought it up. Normally, combining expressions with an operator makes a
> new expression, but that's not true in PHP for the comma. For example,
> f() and g() are expressions, but (f(), g()) is not. That's why,
> presumably, there is no description of what it does in the section on
> operators -- it isn't one!
>
Documentation indicates what you CAN do - not what you CAN'T do. This
is true of languages, databases, spreadsheets and about anything else
around.
> <snip>
>>>> > The lack of formal rigor says that there are some questions which just
>>>> > can't be answered by reading the language documentation.
>>>>
>>>> It can if you have a basic understanding of programming.
>>>
>>> Again, I don't think it's that simple. How would you determine if the
>>> following program is permitted and, if it is, what it does?
>>>
>>> if (false) label: else echo "else\n";
>>> goto label;
>>>
>>> You could try it, of course, but that's hardly very formal.
>>
>> What language gives every possible way for you to screw up your
>> programming?
>
> You seemed to be disagreeing with the statement that there are some
> questions which just can't be answered by reading the language
> documentation. All I was doing was giving an example of a question I
> could not answer from the documentation.
>
See above.
> I agree it's very much a corner case (and many not worth an answer) but
> there are other such questions. For example, from the documentation
> alone I can't explain why ($i++, $j++) is not a valid expression, given
> that it appears to consist of brackets and operators and variables, all
> put together in the usual way.
>
See above. Also, this is PHP, not C or C++.
>> If you want to find out how some screwed-up code works in ANY
>> language, you try it and find out.
>
> That's a flawed method. If I have an algorithm that shifts bits about,
> but sometimes shifts them *all* out, how can I be sure what
>
> 1 << PHP_INT_SIZE*8
>
> really does? If I test it, and it does what I want, can I be sure that
> on some other hardware it will do the same? Does PHP define the
> meaning of this expression, or does it leave it open (and possibly up to
> what the hardware does)?
>
That is how you test anything. And you can NEVER be sure that ANY
operation will work the same when you change compilers/interpreters.
You need to be looking at the documentation for the software you're
using, not something else.
For instance a 32 bit C compiler will have different results than a 64
bit C compiler, even if both are run on a 64 bit machine. And even
different 32 bit C compilers can have different output. For instance,
in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
within the specs (which only states the length of an int is >= the
length of a short, and <= the length of a long). So it is entirely
possible one C compiler will have a 16 bit int, while another has a 32
bit int. And both are within the C spec.
And on 64 bit hardware, an int could be 64 bits long.
> <snip>
>>> 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.
>
> I never suggested otherwise. However, in more rigorously defined
> languages you can find out what combinations are permitted from the
> specification. With PHP, I often end up just trying things because I
> can't find the answer in the documentation. I then assume that what
> happens now is what will always happen -- i.e. that the reference
> implementation is the specification.
>
The PHP doc shows you what combinations are permitted. You are asking
about what is NOT permitted.
>>> 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.
>
> I think that's exactly what it means.
>
Fine. Go ahead and document every possible bad combination of
operators. I won't wait up for your results.
>> But it does mean you are trolling.
>
> Eh? This whole thread is an interesting technical discussion about the
> degree to which PHP programs are well-defined. If you really think my
> contributions are trolling, you know the well-worn advice: don't feed
> me.
>
You claim you understand why things which can't be done are not
documented. Then you argue because what you want to try is not
documented, and denigrate PHP because it doesn't follow YOUR definition
of "rigorously defined".
What else would you call it?
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-24T21:45:26-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185032&th=123426#msg_185032
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> […] Expressions are built from operators, but is ',' an operator in PHP?
>>> It appears in the operator precedence table but it isn't an operator in
>>> an sense that would normally be understood by someone familiar with
>>> these terms.
>>
>> ECMAScript has a “Comma Operator”, too.
>
> But my point was the PHP doesn't have one --
But it does:
for ($i = 0, $j = 42; $i < $j; ++$i);
^
> not in any normal sense of the word.
Please define what you consider to be an operator in a “normal sense of the
word”.
> ECMAScript really does have one (like C and C++ do).
Why do you think C and C++ have a comma operator (like ECMAScript)?
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)]]>Thomas 'PointedEars' 2014-02-24T23:38:41-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185034&th=123426#msg_185034
> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> […] Expressions are built from operators, but is ',' an operator in PHP?
>>>> It appears in the operator precedence table but it isn't an operator in
>>>> an sense that would normally be understood by someone familiar with
>>>> these terms.
>>>
>>> ECMAScript has a “Comma Operator”, too.
>>
>> But my point was the PHP doesn't have one --
>
> But it does:
>
> for ($i = 0, $j = 42; $i < $j; ++$i);
> ^
The comma is used in sevaral places in the PHP grammar[1]. However,
IMHO your example (inside a for_expr) is the only case where the comma
is used as an operator. The other uses are for declaration and
parameter lists (spoken in a broad sense).
>> not in any normal sense of the word.
>
> Please define what you consider to be an operator in a “normal sense of the
> word”.
It might be defined as an operator that can be used in arbitrary
expressions. Consider the following ECMAScript expression:
a = 1, b = 2;
The "equivalent" expression in PHP is a syntax error:
$a = 1, $b = 2;
>> ECMAScript really does have one (like C and C++ do).
>
> Why do you think C and C++ have a comma operator (like ECMAScript)?
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T00:07:19-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185037&th=123426#msg_185037
> On 2/24/2014 12:11 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>
>>>> > On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> >> The original question was a good example of this. the assignment
>>>> >> operator is described as having a precedence (fairly low) just
>>>> >> like all
>>>> >> other operators, with some vague comments that it is done in a way
>>>> >> that
>>>> >> certain things just work. In comments on looking at the code, the
>>>> >> left
>>>> >> operand of assignment is a variable, and not an expression,
>>>> >> effectively
>>>> >> giving assignment a very high precedence to the left, and a very low
>>>> >> precedence to the right (if the grammar even does end up being
>>>> >> actually
>>>> >> describable precisely with precedence). To my knowledge, this
>>>> >> detail is
>>>> >> NOT formally presented in the documentation.
>>>> >
>>>> > No, the original question shows a basic lack of knowledge of terms
>>>> > used in programming. As does your argument.
>>>>
>>>> This puzzles me. What basic knowledge would have cleared up the
>>>> original question?
>>>>
>>>
>>> The definition of "expression". It's something covered in our
>>> "Introduction to Programming" course - which does not cover any
>>> language, only the basic process.
>>
>> Would you mind stating your definition of "expression" here?
>>
>
> I don't think you want MY definition. That will just cause another
> argument. Why don't you look up the common definition of "expression"?
> I'm sure you know how to use Google.
Well, you have claimed that my original question shows a basic lack of
knowledge of terms used in programming", and that the definition of
"expression", what's covered in your "Introduction to Programming"
course would have cleared up my question. So stating this definition
here would be helpful, won't it?
Otherwise it occurs to me that you've made a claim that you can't prove.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T00:25:11-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185038&th=123426#msg_185038
> Thomas 'PointedEars' Lahn wrote:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>>> > […] Expressions are built from operators, but is ',' an operator in
>>>> > [PHP?
>>>> > It appears in the operator precedence table but it isn't an operator
>>>> > in an sense that would normally be understood by someone familiar with
>>>> > these terms.
>>>>
>>>> ECMAScript has a “Comma Operator”, too.
>>>
>>> But my point was the PHP doesn't have one --
>>
>> But it does:
>>
>> for ($i = 0, $j = 42; $i < $j; ++$i);
>> ^
>
> The comma is used in sevaral places in the PHP grammar[1]. However,
> IMHO your example (inside a for_expr) is the only case where the comma
> is used as an operator. The other uses are for declaration and
> parameter lists (spoken in a broad sense).
I am aware of that.
>>> not in any normal sense of the word.
>>
>> Please define what you consider to be an operator in a “normal sense of
>> the word”.
>
> It might be defined as an operator that can be used in arbitrary
> expressions.
A speculation, one that is almost self-evidently false. Just consider the
operators (including, but not just in, programming languages) that require
their operands to be of a certain type.
> Consider the following ECMAScript expression:
>
> a = 1, b = 2;
>
> The "equivalent" expression in PHP is a syntax error:
>
> $a = 1, $b = 2;
ACK; I stand corrected. For reasons I cannot explain (probably it is just
late), I had assumed that the comma operator in ECMAScript also worked with
assignments, and this is what I tested with C and C++:
$ cat foo.c
#include <stdio.h>
int main() {
int x = 42, 23;
printf("%i\n", x);
return 0;
}
$ gcc -Wall -o foo.out foo.c
foo.c: In function ‘main’:
foo.c:4:15: error: expected identifier or ‘(’ before numeric constant
int x = 42, 23;
^
$ cat foo.cpp
#include <iostream>
using namespace std;
int main() {
int x = 42, 23;
cout << x << endl;
return 0;
}
$ g++ -Wall -o foo.out foo.cpp 2>&1| tee /tmp/v6wTKDF/0
foo.cpp: In function ‘int main()’:
foo.cpp:5:15: error: expected unqualified-id before numeric constant
int x = 42, 23;
^
However, in ECMAScript:
| >>> var x = 42, 23;
| SyntaxError: Unexpected number
What I meant instead was
| >>> 42, 23
| 23
which does work like that in certain contexts in C and C++, but not in PHP:
$ cat foo.c
#include <stdio.h>
int main() {
printf("%i\n", (42, 23));
return 0;
}
$ gcc -Wall -o foo.out foo.c 2>&1| tee /tmp/vJ0RqVR/0
foo.c: In function ‘main’:
foo.c:4:21: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
printf("%i\n", (42, 23));
^
$ ./foo.out
23
$ cat foo.cpp
#include <iostream>
using namespace std;
$ g++ -Wall -o foo.out foo.cpp
foo.cpp: In function ‘int main()’:
foo.cpp:5:16: warning: left operand of comma operator has no effect
[-Wunused-value]
cout << (42, 23) << endl;
^
$ ./foo.out
23
$ php -r 'echo (42, 23) . "\n";'
PHP Parse error: syntax error, unexpected ',' in Command line code on line
1
[Interesting that gcc says “operand” and “comma *expression*”, while g++
says “operand” and “comma *operator*”.]
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>]]>Thomas 'PointedEars' 2014-02-25T00:37:26-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185040&th=123426#msg_185040
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Ben Bacarisse wrote:
>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> > Ben Bacarisse wrote:
>>>> >> […] Expressions are built from operators, but is ',' an operator in
>>>> >> [PHP?
>>>> >> It appears in the operator precedence table but it isn't an operator
>>>> >> in an sense that would normally be understood by someone familiar with
>>>> >> these terms.
>>>> >
>>>> > ECMAScript has a “Comma Operator”, too.
>>>>
>>>> But my point was the PHP doesn't have one --
>>>
>>> But it does:
>>>
>>> for ($i = 0, $j = 42; $i < $j; ++$i);
>>> ^
>>
>> The comma is used in sevaral places in the PHP grammar[1]. However,
>> IMHO your example (inside a for_expr) is the only case where the comma
>> is used as an operator. The other uses are for declaration and
>> parameter lists (spoken in a broad sense).
>
> I am aware of that.
>
>>>> not in any normal sense of the word.
>>>
>>> Please define what you consider to be an operator in a “normal sense of
>>> the word”.
>>
>> It might be defined as an operator that can be used in arbitrary
>> expressions.
>
> A speculation,
ACK. :)
> one that is almost self-evidently false. Just consider the
> operators (including, but not just in, programming languages) that require
> their operands to be of a certain type.
I have to admit that this "definition" was far to inaccurate. However,
regarding the syntax alone it has some appeal.
>>>> ECMAScript really does have one (like C and C++ do).
>>>
>>> Why do you think C and C++ have a comma operator (like ECMAScript)?
>>
>> According to the C grammar[2]:
>>
>> exp : assignment_exp
>> | exp ',' assignment_exp
>>
>> [1] <http://lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y>
>> [2] <http://www.cs.man.ac.uk/~pjj/bnf/c_syntax.bnf>
>
> ACK; I stand corrected. For reasons I cannot explain (probably it is just
> late), I had assumed that the comma operator in ECMAScript also worked with
> assignments, and this is what I tested with C and C++:
>
> $ cat foo.c
> #include <stdio.h>
>
> int main() {
> int x = 42, 23;
According to the C grammar[1], this use of the comma is not part of an
"exp", but rather an "init_declarator_list".
> printf("%i\n", x);
> return 0;
> }
>
> $ gcc -Wall -o foo.out foo.c
> foo.c: In function ‘main’:
> foo.c:4:15: error: expected identifier or ‘(’ before numeric constant
> int x = 42, 23;
> ^
>
> However, in ECMAScript:
>
> | >>> var x = 42, 23;
This use of the comma is not part of ECMAScript's "Expression", but
rather of "VariableDeclarationList".
> | SyntaxError: Unexpected number
>
> What I meant instead was
>
> | >>> 42, 23
> | 23
>
> which does work like that in certain contexts in C and C++, but not in PHP:
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T01:12:30-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185041&th=123426#msg_185041
> Jerry Stuckle wrote:
>
>> On 2/24/2014 12:11 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> On 2/23/2014 11:49 PM, Ben Bacarisse wrote:
>>>> > Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> >
>>>> >> On 2/23/2014 6:36 PM, Richard Damon wrote:
>>>> >>> The original question was a good example of this. the assignment
>>>> >>> operator is described as having a precedence (fairly low) just
>>>> >>> like all
>>>> >>> other operators, with some vague comments that it is done in a way
>>>> >>> that
>>>> >>> certain things just work. In comments on looking at the code, the
>>>> >>> left
>>>> >>> operand of assignment is a variable, and not an expression,
>>>> >>> effectively
>>>> >>> giving assignment a very high precedence to the left, and a very low
>>>> >>> precedence to the right (if the grammar even does end up being
>>>> >>> actually
>>>> >>> describable precisely with precedence). To my knowledge, this
>>>> >>> detail is
>>>> >>> NOT formally presented in the documentation.
>>>> >>
>>>> >> No, the original question shows a basic lack of knowledge of terms
>>>> >> used in programming. As does your argument.
>>>> >
>>>> > This puzzles me. What basic knowledge would have cleared up the
>>>> > original question?
>>>> >
>>>>
>>>> The definition of "expression". It's something covered in our
>>>> "Introduction to Programming" course - which does not cover any
>>>> language, only the basic process.
>>>
>>> Would you mind stating your definition of "expression" here?
>>>
>>
>> I don't think you want MY definition. That will just cause another
>> argument. Why don't you look up the common definition of "expression"?
>> I'm sure you know how to use Google.
>
> Well, you have claimed that my original question shows a basic lack of
> knowledge of terms used in programming", and that the definition of
> "expression", what's covered in your "Introduction to Programming"
> course would have cleared up my question. So stating this definition
> here would be helpful, won't it?
>
> Otherwise it occurs to me that you've made a claim that you can't prove.
>
No, I'm not going to fall for your trolling. I told you it was a basic
lack of knowledge of terms. Then I suggested you look up the terms
yourself.
If I give you my definition, it will just give you another excuse to troll.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T01:40:53-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185043&th=123426#msg_185043
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Ben Bacarisse wrote:
>>>> > not in any normal sense of the word.
>>>>
>>>> Please define what you consider to be an operator in a “normal sense of
>>>> the word”.
>>>
>>> It might be defined as an operator that can be used in arbitrary
>>> expressions.
>>
>> A speculation,
>
> ACK. :)
>
>> one that is almost self-evidently false. Just consider
>> the
>> operators (including, but not just in, programming languages) that
>> require their operands to be of a certain type.
>
> I have to admit that this "definition" was far to inaccurate. However,
> regarding the syntax alone it has some appeal.
This “definition” is simply nonsense. An operator is not only an operator
when it “can be used in arbitrary expressions”. In mathematics, from which
is the definition that fits best here, an operator is a mapping from
elements of one or more sets to elements of another or to the same set. So
*by definition* its context and its operands (members of said sets) matter.
>>>> > ECMAScript really does have one (like C and C++ do).
>>>>
>>>> Why do you think C and C++ have a comma operator (like ECMAScript)?
>>>
>>> According to the C grammar[2]:
>>>
>>> exp : assignment_exp
>>> | exp ',' assignment_exp
>>>
>>> [1] <http://lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y>
>>> [2] <http://www.cs.man.ac.uk/~pjj/bnf/c_syntax.bnf>
>>
>> ACK; I stand corrected. For reasons I cannot explain (probably it is
^^^^^^^^^^^^^^^^^
>> just late), I had assumed that the comma operator in ECMAScript also
>> worked with assignments, and this is what I tested with C and C++:
>>
>> $ cat foo.c
>> #include <stdio.h>
>>
>> int main() {
>> int x = 42, 23;
>
> According to the C grammar[1], this use of the comma is not part of an
> "exp", but rather an "init_declarator_list".
>
>> […] printf("%i\n", x);
>> return 0;
>> }
>>
>> $ gcc -Wall -o foo.out foo.c
>> foo.c: In function ‘main’:
>> foo.c:4:15: error: expected identifier or ‘(’ before numeric constant
>> int x = 42, 23;
>> ^
>>
>> However, in ECMAScript:
>>
>> | >>> var x = 42, 23;
>
> This use of the comma is not part of ECMAScript's "Expression", but
> rather of "VariableDeclarationList".
Please stop telling me things I know:
>> | SyntaxError: Unexpected number
>>
>> What I meant instead was
>>
>> | >>> 42, 23
>> | 23
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).]]>Thomas 'PointedEars' 2014-02-25T02:29:29-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185049&th=123426#msg_185049
PointedEars@web.de> writes:
> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> […] Expressions are built from operators, but is ',' an operator in PHP?
>>>> It appears in the operator precedence table but it isn't an operator in
>>>> an sense that would normally be understood by someone familiar with
>>>> these terms.
>>>
>>> ECMAScript has a “Comma Operator”, too.
>>
>> But my point was the PHP doesn't have one --
>
> But it does:
>
> for ($i = 0, $j = 42; $i < $j; ++$i);
But try this:
for (($i = 0, $j = 42); $i < $j; ++$i);
In general, putting an expression in parentheses does not stop it being
an expression. The permission to use ',' in a for statement is special
syntax: it's not part of the syntax for an expression. To give another
example, if the ',' in a for statement built an expression you should be
able to change:
for ($i = 0; f($1), $i < 10; $i++) { ...; }
into
$i = 0;
while (f($1), $i < 10) { ...; $i++; }
but you can't, because while takes an expression as the condition, and
f($i), $i < 10 is not an expression!
>> not in any normal sense of the word.
>
> Please define what you consider to be an operator in a “normal sense of the
> word”.
It's a syntactic symbol that can be used to combine simpler expressions
in such a way that the result is also, syntactically, an expression. In
PHP, you can't take two expressions (E1) and (E2) and write ((E1), (E2))
to get a new expression - the syntax for expressions simply doesn't
permit the use of ',' as an operator.
>> ECMAScript really does have one (like C and C++ do).
>
> Why do you think C and C++ have a comma operator (like ECMAScript)?
Because they do.
--
Ben.]]>Ben Bacarisse2014-02-25T03:08:40-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185050&th=123426#msg_185050
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>>> > […] Expressions are built from operators, but is ',' an operator in
>>>> > [PHP?
>>>> > It appears in the operator precedence table but it isn't an operator
>>>> > in an sense that would normally be understood by someone familiar with
>>>> > these terms.
>>>>
>>>> ECMAScript has a “Comma Operator”, too.
>>>
>>> But my point was the PHP doesn't have one --
>>
>> But it does:
>>
>> for ($i = 0, $j = 42; $i < $j; ++$i);
>
> But try this:
>
> for (($i = 0, $j = 42); $i < $j; ++$i);
Bogus example.
> In general, putting an expression in parentheses does not stop it being
> an expression.
>
> The permission to use ',' in a for statement is special
> syntax: it's not part of the syntax for an expression. To give another
> example, if the ',' in a for statement built an expression you should be
> able to change:
>
> for ($i = 0; f($1), $i < 10; $i++) { ...; }
>
> into
>
> $i = 0;
> while (f($1), $i < 10) { ...; $i++; }
>
> but you can't, because while takes an expression as the condition, and
> f($i), $i < 10 is not an expression!
Irrelevant.
>>> not in any normal sense of the word.
>>
>> Please define what you consider to be an operator in a “normal sense of
>> the word”.
>
> It's a syntactic symbol that can be used to combine simpler expressions
> in such a way that the result is also, syntactically, an expression.
A very narrow definition of “operator”.
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>]]>Thomas 'PointedEars' 2014-02-25T03:17:45-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185052&th=123426#msg_185052
> 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.
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?
....
>> 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.
>
>> 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.]]>Richard Damon2014-02-25T03:41:12-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185053&th=123426#msg_185053
jstucklex@attglobal.net> writes:
> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>> It is an operator, as indicated by its appearance in the table of
>>> operators. Operators are not limited to +-*/.
>>
>> I am familiar with languages that have a ',' operator, which is why I
>> brought it up. Normally, combining expressions with an operator makes a
>> new expression, but that's not true in PHP for the comma. For example,
>> f() and g() are expressions, but (f(), g()) is not. That's why,
>> presumably, there is no description of what it does in the section on
>> operators -- it isn't one!
>
> Documentation indicates what you CAN do - not what you CAN'T do. This
> is true of languages, databases, spreadsheets and about anything else
> around.
What can you do with the ',' operator? From the PHP documentation:
An operator is something that takes one or more values (or
expressions, in programming jargon) and yields another value (so that
the construction itself becomes an expression).
I can't see any usage of ',' that matches this definition. By the
manual's own definition, ',' in not an operator in PHP.
As to your general point, the C language standard is an excellent
example of documentation that says both what you can do and what you
can't do. In extreme cases the distinction disappears, because a
language that specifies exactly what can be done, implicitly defines
what can't. But n practice it's easier to do a bit of both. For
example, you might give a general grammar, and then explain some
restrictions, such as what forms are not permitted on the left of an
assignment.
>> <snip>
>>>> >> The lack of formal rigor says that there are some questions which just
>>>> >> can't be answered by reading the language documentation.
>>>> >
>>>> > It can if you have a basic understanding of programming.
>>>>
>>>> Again, I don't think it's that simple. How would you determine if the
>>>> following program is permitted and, if it is, what it does?
>>>>
>>>> if (false) label: else echo "else\n";
>>>> goto label;
>>>>
>>>> You could try it, of course, but that's hardly very formal.
>>>
>>> What language gives every possible way for you to screw up your
>>> programming?
>>
>> You seemed to be disagreeing with the statement that there are some
>> questions which just can't be answered by reading the language
>> documentation. All I was doing was giving an example of a question I
>> could not answer from the documentation.
>
> See above.
So you think my example is of something that can't be done and that is
why you can't tell what the code done by
>
>> I agree it's very much a corner case (and many not worth an answer) but
>> there are other such questions. For example, from the documentation
>> alone I can't explain why ($i++, $j++) is not a valid expression, given
>> that it appears to consist of brackets and operators and variables, all
>> put together in the usual way.
>>
>
> See above. Also, this is PHP, not C or C++.
>
>>> If you want to find out how some screwed-up code works in ANY
>>> language, you try it and find out.
>>
>> That's a flawed method. If I have an algorithm that shifts bits about,
>> but sometimes shifts them *all* out, how can I be sure what
>>
>> 1 << PHP_INT_SIZE*8
>>
>> really does? If I test it, and it does what I want, can I be sure that
>> on some other hardware it will do the same? Does PHP define the
>> meaning of this expression, or does it leave it open (and possibly up to
>> what the hardware does)?
>>
>
> That is how you test anything. And you can NEVER be sure that ANY
> operation will work the same when you change
> compilers/interpreters. You need to be looking at the documentation
> for the software you're using, not something else.
>
> For instance a 32 bit C compiler will have different results than a 64
> bit C compiler, even if both are run on a 64 bit machine. And even
> different 32 bit C compilers can have different output. For instance,
> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
> within the specs
No, C does no permit int to be less that 16 bits wide -- 8 is not
allowed.
> (which only states the length of an int is >= the
> length of a short, and <= the length of a long). So it is entirely
> possible one C compiler will have a 16 bit int, while another has a 32
> bit int. And both are within the C spec.
Yes, but the language gives minimum guarantees which can be used to
permit code to be ported. It also (often) explicitly says where there
is no guarantee. For example, shifting right by the width of the type
being shifted is explicitly "undefined". It's useful to know that,
because you can simply avoid the situation in the first place. That's
simpler that testing it, seeing that it does what you expect, and then
finding that it fails on some other hardware.
> And on 64 bit hardware, an int could be 64 bits long.
More surprisingly, so could a char!
>> <snip>
>>>> 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.
>>
>> I never suggested otherwise. However, in more rigorously defined
>> languages you can find out what combinations are permitted from the
>> specification. With PHP, I often end up just trying things because I
>> can't find the answer in the documentation. I then assume that what
>> happens now is what will always happen -- i.e. that the reference
>> implementation is the specification.
>>
> The PHP doc shows you what combinations are permitted. You are asking
> about what is NOT permitted.
Yes, because that is part of the specification of the language. Aren't
you curious to know what expression forms are permitted on the left of
an assignment? Would you not find a grammar for PHP to be a useful part
of the documentation? These thing seem unexceptional to me.
<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.
>>
>> I think that's exactly what it means.
>
> Fine. Go ahead and document every possible bad combination of
> operators. I won't wait up for your results.
Well, I'd rather not. PHP has a more special cases than other languages
I've used, so it would be harder than for those. But I am surprised
that that you think it's so unreasonable to expect at least a moderately
rigorous definition of what is and is not permitted. As I said before,
it seems perfect reasonable to me. Even a grammar for the language
(surely not that hard) would have eliminated the OP's question from the
get go.
>>> But it does mean you are trolling.
>>
>> Eh? This whole thread is an interesting technical discussion about the
>> degree to which PHP programs are well-defined. If you really think my
>> contributions are trolling, you know the well-worn advice: don't feed
>> me.
>
> You claim you understand why things which can't be done are not
> documented. Then you argue because what you want to try is not
> documented, and denigrate PHP because it doesn't follow YOUR
> definition of "rigorously defined".
I don't recognise any of that.
I was making a sound technical point in reply to you: that PHP does not
have a ',' operator except in some sort of literalist sense: the manual
says it does, so it does, despite the fact that its meaning is undefined
and you can't use it in expressions to make bigger expressions.
Your counter argument seems to be that the manual is not obliged to
document what you can't do. I disagree about that, but even if this is
granted, it is surely a mistake to list ',' as an operator when it
clearly isn't.
> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> > Ben Bacarisse wrote:
>>>> >> […] Expressions are built from operators, but is ',' an operator in
>>>> >> [PHP?
>>>> >> It appears in the operator precedence table but it isn't an operator
>>>> >> in an sense that would normally be understood by someone familiar with
>>>> >> these terms.
>>>> >
>>>> > ECMAScript has a “Comma Operator”, too.
>>>>
>>>> But my point was the PHP doesn't have one --
>>>
>>> But it does:
>>>
>>> for ($i = 0, $j = 42; $i < $j; ++$i);
>>
>> But try this:
>>
>> for (($i = 0, $j = 42); $i < $j; ++$i);
>
> Bogus example.
>
>> In general, putting an expression in parentheses does not stop it being
>> an expression.
This is why it's not bogus. By all means explain why your understanding
of what an operator permits the construction of something that is not an
expression, but don't just say "bogus".
I contend that for ',' to be an operator, it should form part of an
expression, and I contend that expressions can be put in parentheses and
remain expressions. You can challenge either notion, but then I think
we will be disagreeing only about definitions.
<snip>
>>> Please define what you consider to be an operator in a “normal sense of
>>> the word”.
>>
>> It's a syntactic symbol that can be used to combine simpler expressions
>> in such a way that the result is also, syntactically, an expression.
>
> A very narrow definition of “operator”.
Maybe, but it comports with what PHP considers to be an operator:
"An operator is something that takes one or more values (or
expressions, in programming jargon) and yields another value (so that
the construction itself becomes an expression)."
If you have a different definition, we could just agree on the fact that
PHP has no ',' operator as PHP defines the term.
What is your definition?
--
Ben.]]>Ben Bacarisse2014-02-25T04:45:17-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185055&th=123426#msg_185055
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
> <snip>
>>>> It is an operator, as indicated by its appearance in the table of
>>>> operators. Operators are not limited to +-*/.
>>>
>>> I am familiar with languages that have a ',' operator, which is why I
>>> brought it up. Normally, combining expressions with an operator makes a
>>> new expression, but that's not true in PHP for the comma. For example,
>>> f() and g() are expressions, but (f(), g()) is not. That's why,
>>> presumably, there is no description of what it does in the section on
>>> operators -- it isn't one!
>>
>> Documentation indicates what you CAN do - not what you CAN'T do. This
>> is true of languages, databases, spreadsheets and about anything else
>> around.
>
> What can you do with the ',' operator? From the PHP documentation:
>
Where in the PHP manual does it say ',' is an operator?
> An operator is something that takes one or more values (or
> expressions, in programming jargon) and yields another value (so that
> the construction itself becomes an expression).
>
> I can't see any usage of ',' that matches this definition. By the
> manual's own definition, ',' in not an operator in PHP.
>
> As to your general point, the C language standard is an excellent
> example of documentation that says both what you can do and what you
> can't do. In extreme cases the distinction disappears, because a
> language that specifies exactly what can be done, implicitly defines
> what can't. But n practice it's easier to do a bit of both. For
> example, you might give a general grammar, and then explain some
> restrictions, such as what forms are not permitted on the left of an
> assignment.
>
No, the C specification does NOT say what you cannot do. Some books may
add some things you cannot do, but the language itself doesn't. Check
it out yourself - it's available at the ANSI website (for a price).
Some university and/or technical libraries also have a copy.
>>> <snip>
>>>> >>> The lack of formal rigor says that there are some questions which just
>>>> >>> can't be answered by reading the language documentation.
>>>> >>
>>>> >> It can if you have a basic understanding of programming.
>>>> >
>>>> > Again, I don't think it's that simple. How would you determine if the
>>>> > following program is permitted and, if it is, what it does?
>>>> >
>>>> > if (false) label: else echo "else\n";
>>>> > goto label;
>>>> >
>>>> > You could try it, of course, but that's hardly very formal.
>>>>
>>>> What language gives every possible way for you to screw up your
>>>> programming?
>>>
>>> You seemed to be disagreeing with the statement that there are some
>>> questions which just can't be answered by reading the language
>>> documentation. All I was doing was giving an example of a question I
>>> could not answer from the documentation.
>>
>> See above.
>
> So you think my example is of something that can't be done and that is
> why you can't tell what the code done by
If it's not documented that you can do it, you can try it and see if it
works. But beware that undocumented "features" may or may not act the
same way in the next release.
>>
>>> I agree it's very much a corner case (and many not worth an answer) but
>>> there are other such questions. For example, from the documentation
>>> alone I can't explain why ($i++, $j++) is not a valid expression, given
>>> that it appears to consist of brackets and operators and variables, all
>>> put together in the usual way.
>>>
>>
>> See above. Also, this is PHP, not C or C++.
>>
>>>> If you want to find out how some screwed-up code works in ANY
>>>> language, you try it and find out.
>>>
>>> That's a flawed method. If I have an algorithm that shifts bits about,
>>> but sometimes shifts them *all* out, how can I be sure what
>>>
>>> 1 << PHP_INT_SIZE*8
>>>
>>> really does? If I test it, and it does what I want, can I be sure that
>>> on some other hardware it will do the same? Does PHP define the
>>> meaning of this expression, or does it leave it open (and possibly up to
>>> what the hardware does)?
>>>
>>
>> That is how you test anything. And you can NEVER be sure that ANY
>> operation will work the same when you change
>> compilers/interpreters. You need to be looking at the documentation
>> for the software you're using, not something else.
>>
>> For instance a 32 bit C compiler will have different results than a 64
>> bit C compiler, even if both are run on a 64 bit machine. And even
>> different 32 bit C compilers can have different output. For instance,
>> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>> within the specs
>
> No, C does no permit int to be less that 16 bits wide -- 8 is not
> allowed.
>
Actually, the ANSI C spec DOES allow it. The spec sets no hard minimum
or maximum for the size of any of the numeric values. C can still run
on 8 bit processors, also (as in imbedded systems).
>> (which only states the length of an int is >= the
>> length of a short, and <= the length of a long). So it is entirely
>> possible one C compiler will have a 16 bit int, while another has a 32
>> bit int. And both are within the C spec.
>
> Yes, but the language gives minimum guarantees which can be used to
> permit code to be ported. It also (often) explicitly says where there
> is no guarantee. For example, shifting right by the width of the type
> being shifted is explicitly "undefined". It's useful to know that,
> because you can simply avoid the situation in the first place. That's
> simpler that testing it, seeing that it does what you expect, and then
> finding that it fails on some other hardware.
>
The only minimum is that an int must not be smaller than a short.
>> And on 64 bit hardware, an int could be 64 bits long.
>
> More surprisingly, so could a char!
>
>>> <snip>
>>>> > 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.
>>>
>>> I never suggested otherwise. However, in more rigorously defined
>>> languages you can find out what combinations are permitted from the
>>> specification. With PHP, I often end up just trying things because I
>>> can't find the answer in the documentation. I then assume that what
>>> happens now is what will always happen -- i.e. that the reference
>>> implementation is the specification.
>>>
>> The PHP doc shows you what combinations are permitted. You are asking
>> about what is NOT permitted.
>
> Yes, because that is part of the specification of the language. Aren't
> you curious to know what expression forms are permitted on the left of
> an assignment? Would you not find a grammar for PHP to be a useful part
> of the documentation? These thing seem unexceptional to me.
>
No, the specification of a language states only what is allowed. For
instance, the C++ spec specifies which operators may be overridden. It
does NOT specify that the '.' operator may not be overridden.
> <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.
>>>
>>> I think that's exactly what it means.
>>
>> Fine. Go ahead and document every possible bad combination of
>> operators. I won't wait up for your results.
>
> Well, I'd rather not. PHP has a more special cases than other languages
> I've used, so it would be harder than for those. But I am surprised
> that that you think it's so unreasonable to expect at least a moderately
> rigorous definition of what is and is not permitted. As I said before,
> it seems perfect reasonable to me. Even a grammar for the language
> (surely not that hard) would have eliminated the OP's question from the
> get go.
>
PHP is documented exactly the same as all of the other 20-odd languages
I've used over the years. About the only difference is that PHP doc is
written in a friendlier language (have you ever read an ANSI spec, for
instance?).
>>>> But it does mean you are trolling.
>>>
>>> Eh? This whole thread is an interesting technical discussion about the
>>> degree to which PHP programs are well-defined. If you really think my
>>> contributions are trolling, you know the well-worn advice: don't feed
>>> me.
>>
>> You claim you understand why things which can't be done are not
>> documented. Then you argue because what you want to try is not
>> documented, and denigrate PHP because it doesn't follow YOUR
>> definition of "rigorously defined".
>
> I don't recognise any of that.
>
Why not? It's exactly what you are saying.
> I was making a sound technical point in reply to you: that PHP does not
> have a ',' operator except in some sort of literalist sense: the manual
> says it does, so it does, despite the fact that its meaning is undefined
> and you can't use it in expressions to make bigger expressions.
>
I never claimed it does. Where in the manual does it say you can use
the ',' operator like you want?
> Your counter argument seems to be that the manual is not obliged to
> document what you can't do. I disagree about that, but even if this is
> granted, it is surely a mistake to list ',' as an operator when it
> clearly isn't.
>
> <snip>
>
Exactly. The manual is obliged to only document what you can do. That
is true for any language.
Please show where in the manual it shows you can use the ',' operator
like you want.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T04:47:27-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185056&th=123426#msg_185056
> 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 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.
> 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.
>
>
>>> 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.
>
>>
>>> 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.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T04:59:02-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185060&th=123426#msg_185060
jstucklex@attglobal.net> writes:
> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> <snip>
>>>> > It is an operator, as indicated by its appearance in the table of
>>>> > operators. Operators are not limited to +-*/.
>>>>
>>>> I am familiar with languages that have a ',' operator, which is why I
>>>> brought it up. Normally, combining expressions with an operator makes a
>>>> new expression, but that's not true in PHP for the comma. For example,
>>>> f() and g() are expressions, but (f(), g()) is not. That's why,
>>>> presumably, there is no description of what it does in the section on
>>>> operators -- it isn't one!
>>>
>>> Documentation indicates what you CAN do - not what you CAN'T do. This
>>> is true of languages, databases, spreadsheets and about anything else
>>> around.
>>
>> What can you do with the ',' operator? From the PHP documentation:
>
> Where in the PHP manual does it say ',' is an operator?
"A full list of PHP operators follows in the section Operator
Precedence." (which is the section immediately following)
That list includes ',' as you yourself stated:
"It is an operator, as indicated by its appearance in the table of
operators. Operators are not limited to +-*/.".
But if that is no longer your position, then we are in agreement.
<snip>
>> As to your general point, the C language standard is an excellent
>> example of documentation that says both what you can do and what you
>> can't do. In extreme cases the distinction disappears, because a
>> language that specifies exactly what can be done, implicitly defines
>> what can't. But n practice it's easier to do a bit of both. For
>> example, you might give a general grammar, and then explain some
>> restrictions, such as what forms are not permitted on the left of an
>> assignment.
>
> No, the C specification does NOT say what you cannot do. Some books
> may add some things you cannot do, but the language itself doesn't.
> Check it out yourself - it's available at the ANSI website (for a
> price). Some university and/or technical libraries also have a copy.
How many examples would you like? For example, the C standard gives a
grammar for expressions and then, for each operator, it gives
constraints on that general form. The grammar permits 1 = 1, but the
constraints on the = operator state that the expression on the left hand
side must be a modifiable lvalue. The upshot is that you can tell what
forms of expression are and are not permitted. In particular, C does
not permit (cond ? a : b) = expr; but C++ does.
PHP is, as far as I can tell, silent on this matter. Don't you think
some more clarity about what is permitted and what is not permitted
would be useful?
(If you want to make a linguistic point that a constraint on what you
can do is not the same as saying that you cannot do something, then I
refer you to my C++ quote below.)
<snip>
>>> For instance a 32 bit C compiler will have different results than a 64
>>> bit C compiler, even if both are run on a 64 bit machine. And even
>>> different 32 bit C compilers can have different output. For instance,
>>> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>> within the specs
>>
>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>> allowed.
>
> Actually, the ANSI C spec DOES allow it. The spec sets no hard
> minimum or maximum for the size of any of the numeric values. C can
> still run on 8 bit processors, also (as in imbedded systems).
It seems odd to be disagreeing about easily verifiable facts. ANSI C is
often used to refer to the first C standard (1989), in which case look
at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
standard, that's ISO/IEC 9899:2011 and the section you need is
"5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
section from each that states that the constraints imposed by limits.h
apply to both hosted and free-standing implementations.)
>>> (which only states the length of an int is >= the
>>> length of a short, and <= the length of a long). So it is entirely
>>> possible one C compiler will have a 16 bit int, while another has a 32
>>> bit int. And both are within the C spec.
>>
>> Yes, but the language gives minimum guarantees which can be used to
>> permit code to be ported. It also (often) explicitly says where there
>> is no guarantee. For example, shifting right by the width of the type
>> being shifted is explicitly "undefined". It's useful to know that,
>> because you can simply avoid the situation in the first place. That's
>> simpler that testing it, seeing that it does what you expect, and then
>> finding that it fails on some other hardware.
>
> The only minimum is that an int must not be smaller than a short.
No, there are others -- in particular, a minimum range of representable
values for each of the standard integer types. For int it is from
-32767 to +32767.
<snip>
>>> The PHP doc shows you what combinations are permitted. You are asking
>>> about what is NOT permitted.
>>
>> Yes, because that is part of the specification of the language. Aren't
>> you curious to know what expression forms are permitted on the left of
>> an assignment? Would you not find a grammar for PHP to be a useful part
>> of the documentation? These thing seem unexceptional to me.
>
> No, the specification of a language states only what is allowed. For
> instance, the C++ spec specifies which operators may be overridden.
> It does NOT specify that the '.' operator may not be overridden.
Are you just saying wrong things to wind me up? Section 13.5
"Overloaded operators" of the current C++ standard says:
"The following operators cannot be overloaded:
. .* :: ?:"
Similar wording exists in the 1998 and 2003 standards.
<snip>
> PHP is documented exactly the same as all of the other 20-odd
> languages I've used over the years. About the only difference is that
> PHP doc is written in a friendlier language (have you ever read an
> ANSI spec, for instance?).
Given the above, I think you can conclude that I have. But we do agree:
I like the informal, friendly, language of the reference manual. But
for many other languages I've used, there is also a relatively rigorous
specification that forgoes friendly language in order to answer exactly
the kind of questions that I and OP raised in this thread. It's not
essential, and I understand why no one wants to produce it, but that it
would be a good idea does not seem to me to be at all controversial.
<snip>
> Please show where in the manual it shows you can use the ',' operator
> like you want.
I don't want to use it in any particular way. In that, the manual is
100% correct because it says nothing at all about how one might use ','
in the way it describes operators as working. Bun I was just querying
your statement that it is one. If you don't think it's an operator, we
are in agreement about that.
--
Ben.]]>Ben Bacarisse2014-02-25T16:56:18-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185061&th=123426#msg_185061
> 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.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T18:15:15-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185063&th=123426#msg_185063
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>> > Ben Bacarisse wrote:
>>>> >> not in any normal sense of the word.
>>>> >
>>>> > Please define what you consider to be an operator in a “normal sense of
>>>> > the word”.
>>>>
>>>> It might be defined as an operator that can be used in arbitrary
>>>> expressions.
>>>
>>> A speculation,
>>
>> ACK. :)
>>
>>> one that is almost self-evidently false. Just consider
>>> the
>>> operators (including, but not just in, programming languages) that
>>> require their operands to be of a certain type.
>>
>> I have to admit that this "definition" was far to inaccurate. However,
>> regarding the syntax alone it has some appeal.
>
> This “definition” is simply nonsense. An operator is not only an operator
> when it “can be used in arbitrary expressions”. In mathematics, from which
> is the definition that fits best here, an operator is a mapping from
> elements of one or more sets to elements of another or to the same set.
That sounds "very similar" to the definition of a function. ;)
> So
> *by definition* its context and its operands (members of said sets) matter.
>
>>>> >> ECMAScript really does have one (like C and C++ do).
>>>> >
>>>> > Why do you think C and C++ have a comma operator (like ECMAScript)?
>>>>
>>>> According to the C grammar[2]:
>>>>
>>>> exp : assignment_exp
>>>> | exp ',' assignment_exp
>>>>
>>>> [1] <http://lxr.php.net/xref/PHP_5_5/Zend/zend_language_parser.y>
>>>> [2] <http://www.cs.man.ac.uk/~pjj/bnf/c_syntax.bnf>
>>>
>>> ACK; I stand corrected. For reasons I cannot explain (probably it is
> ^^^^^^^^^^^^^^^^^
>>> just late), I had assumed that the comma operator in ECMAScript also
>>> worked with assignments, and this is what I tested with C and C++:
>>>
>>> $ cat foo.c
>>> #include <stdio.h>
>>>
>>> int main() {
>>> int x = 42, 23;
>>
>> According to the C grammar[1], this use of the comma is not part of an
>> "exp", but rather an "init_declarator_list".
>>
>>> […] printf("%i\n", x);
>>> return 0;
>>> }
>>>
>>> $ gcc -Wall -o foo.out foo.c
>>> foo.c: In function ‘main’:
>>> foo.c:4:15: error: expected identifier or ‘(’ before numeric constant
>>> int x = 42, 23;
>>> ^
>>>
>>> However, in ECMAScript:
>>>
>>> | >>> var x = 42, 23;
>>
>> This use of the comma is not part of ECMAScript's "Expression", but
>> rather of "VariableDeclarationList".
>
> Please stop telling me things I know:
I have posted a message to Usenet. If you already knew these details,
fine. However, other readers might not.
Furthermore I was trying to stress my (resp. Ben's) point, that a comma
is not always an operator, even if a language defines a comma operator.
>>> | SyntaxError: Unexpected number
>>>
>>> What I meant instead was
>>>
>>> | >>> 42, 23
>>> | 23
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T18:41:35-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185064&th=123426#msg_185064
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>> > Thomas 'PointedEars' Lahn wrote:
>>>> >> Ben Bacarisse wrote:
>>>> >>> not in any normal sense of the word.
>>>> >> Please define what you consider to be an operator in a “normal sense
>>>> >> of the word”.
>>>> > It might be defined as an operator that can be used in arbitrary
>>>> > expressions.
>>>> A speculation, one that is almost self-evidently false. Just consider
>>>> the operators (including, but not just in, programming languages) that
>>>> require their operands to be of a certain type.
>>>
>>> I have to admit that this "definition" was far to inaccurate. However,
>>> regarding the syntax alone it has some appeal.
>>
>> This “definition” is simply nonsense. An operator is not only an
>> operator when it “can be used in arbitrary expressions”. In mathematics,
>> from which is the definition that fits best here, an operator is a
>> mapping from elements of one or more sets to elements of another or to
>> the same set.
>
> That sounds "very similar" to the definition of a function. ;)
Yes, this is not a coincidence.
>>>> However, in ECMAScript:
>>>>
>>>> | >>> var x = 42, 23;
>>>
>>> This use of the comma is not part of ECMAScript's "Expression", but
>>> rather of "VariableDeclarationList".
>>
>> Please stop telling me things I know:
>
> I have posted a message to Usenet. If you already knew these details,
> fine. However, other readers might not.
I had already conceded that I was wrong, and explained why. You have been
preaching to the choir.
> Furthermore I was trying to stress my (resp. Ben's) point, that a comma
> is not always an operator, even if a language defines a comma operator.
No disagreement there. However, strange as it may seem, without proof to
the contrary “,” *is* an operator in PHP. That it is one is not negated by
its being of limited use (which contradicts the manual; we may assume that
it was intended to work like in C/C++/ECMAScript, but was never implemented
this way; a documentation bug should be filed).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann]]>Thomas 'PointedEars' 2014-02-25T18:55:28-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185065&th=123426#msg_185065
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>>>> > Jerry Stuckle <jstucklex@attglobal.net> writes:
>>> <snip>
>>>> >> It is an operator, as indicated by its appearance in the table of
>>>> >> operators. Operators are not limited to +-*/.
>>>> >
>>>> > I am familiar with languages that have a ',' operator, which is why I
>>>> > brought it up. Normally, combining expressions with an operator makes a
>>>> > new expression, but that's not true in PHP for the comma. For example,
>>>> > f() and g() are expressions, but (f(), g()) is not. That's why,
>>>> > presumably, there is no description of what it does in the section on
>>>> > operators -- it isn't one!
>>>>
>>>> Documentation indicates what you CAN do - not what you CAN'T do. This
>>>> is true of languages, databases, spreadsheets and about anything else
>>>> around.
>>>
>>> What can you do with the ',' operator? From the PHP documentation:
>>
>> Where in the PHP manual does it say ',' is an operator?
>
> "A full list of PHP operators follows in the section Operator
> Precedence." (which is the section immediately following)
>
> That list includes ',' as you yourself stated:
>
> "It is an operator, as indicated by its appearance in the table of
> operators. Operators are not limited to +-*/.".
>
> But if that is no longer your position, then we are in agreement.
>
OK, it does show up in the operator precedence table. But it also says
"many uses". It doesn't define those uses in the table; it doesn't tell
you what you can't do.
> <snip>
>>> As to your general point, the C language standard is an excellent
>>> example of documentation that says both what you can do and what you
>>> can't do. In extreme cases the distinction disappears, because a
>>> language that specifies exactly what can be done, implicitly defines
>>> what can't. But n practice it's easier to do a bit of both. For
>>> example, you might give a general grammar, and then explain some
>>> restrictions, such as what forms are not permitted on the left of an
>>> assignment.
>>
>> No, the C specification does NOT say what you cannot do. Some books
>> may add some things you cannot do, but the language itself doesn't.
>> Check it out yourself - it's available at the ANSI website (for a
>> price). Some university and/or technical libraries also have a copy.
>
> How many examples would you like? For example, the C standard gives a
> grammar for expressions and then, for each operator, it gives
> constraints on that general form. The grammar permits 1 = 1, but the
> constraints on the = operator state that the expression on the left hand
> side must be a modifiable lvalue. The upshot is that you can tell what
> forms of expression are and are not permitted. In particular, C does
> not permit (cond ? a : b) = expr; but C++ does.
>
Exactly. It tells you what you CAN do. It does not tell you what you
cannot do.
> PHP is, as far as I can tell, silent on this matter. Don't you think
> some more clarity about what is permitted and what is not permitted
> would be useful?
>
> (If you want to make a linguistic point that a constraint on what you
> can do is not the same as saying that you cannot do something, then I
> refer you to my C++ quote below.)
>
If you don't like the doc, submit a bug report for it.
> <snip>
>>>> For instance a 32 bit C compiler will have different results than a 64
>>>> bit C compiler, even if both are run on a 64 bit machine. And even
>>>> different 32 bit C compilers can have different output. For instance,
>>>> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>> within the specs
>>>
>>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>>> allowed.
>>
>> Actually, the ANSI C spec DOES allow it. The spec sets no hard
>> minimum or maximum for the size of any of the numeric values. C can
>> still run on 8 bit processors, also (as in imbedded systems).
>
> It seems odd to be disagreeing about easily verifiable facts. ANSI C is
> often used to refer to the first C standard (1989), in which case look
> at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
> standard, that's ISO/IEC 9899:2011 and the section you need is
> "5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
> section from each that states that the constraints imposed by limits.h
> apply to both hosted and free-standing implementations.)
>
As I said before - I wore my ANSI C standard out and tossed it quite a
while back. But even then it did not specify a minimum of 16 bits for
an integer. There are still 8 bit processors and compilers out there.
>>>> (which only states the length of an int is >= the
>>>> length of a short, and <= the length of a long). So it is entirely
>>>> possible one C compiler will have a 16 bit int, while another has a 32
>>>> bit int. And both are within the C spec.
>>>
>>> Yes, but the language gives minimum guarantees which can be used to
>>> permit code to be ported. It also (often) explicitly says where there
>>> is no guarantee. For example, shifting right by the width of the type
>>> being shifted is explicitly "undefined". It's useful to know that,
>>> because you can simply avoid the situation in the first place. That's
>>> simpler that testing it, seeing that it does what you expect, and then
>>> finding that it fails on some other hardware.
>>
>> The only minimum is that an int must not be smaller than a short.
>
> No, there are others -- in particular, a minimum range of representable
> values for each of the standard integer types. For int it is from
> -32767 to +32767.
>
Then please tell me how an 8 bit compiler can be ANSI Standard? There
are some out there. It's been a while since I did any work on one, but
I know of several embedded systems which are still in use (and being
updated).
> <snip>
>>>> The PHP doc shows you what combinations are permitted. You are asking
>>>> about what is NOT permitted.
>>>
>>> Yes, because that is part of the specification of the language. Aren't
>>> you curious to know what expression forms are permitted on the left of
>>> an assignment? Would you not find a grammar for PHP to be a useful part
>>> of the documentation? These thing seem unexceptional to me.
>>
>> No, the specification of a language states only what is allowed. For
>> instance, the C++ spec specifies which operators may be overridden.
>> It does NOT specify that the '.' operator may not be overridden.
>
> Are you just saying wrong things to wind me up? Section 13.5
> "Overloaded operators" of the current C++ standard says:
>
> "The following operators cannot be overloaded:
> . .* :: ?:"
>
> Similar wording exists in the 1998 and 2003 standards.
>
That has changed in the standard, then. It used to not specify those
operators which cannot be overloaded.
> <snip>
>> PHP is documented exactly the same as all of the other 20-odd
>> languages I've used over the years. About the only difference is that
>> PHP doc is written in a friendlier language (have you ever read an
>> ANSI spec, for instance?).
>
> Given the above, I think you can conclude that I have. But we do agree:
> I like the informal, friendly, language of the reference manual. But
> for many other languages I've used, there is also a relatively rigorous
> specification that forgoes friendly language in order to answer exactly
> the kind of questions that I and OP raised in this thread. It's not
> essential, and I understand why no one wants to produce it, but that it
> would be a good idea does not seem to me to be at all controversial.
>
No, I can't conclude that you have read anything. All I know is that
you've googled for excerpts from it.
If you want to produce a "rigorous standard", you are free to do so.
But standards are mainly for compiler developers; since there is only
one, I don't see a need for it (and I doubt ZEND would pay any attention
to it, anyway).
> <snip>
>> Please show where in the manual it shows you can use the ',' operator
>> like you want.
>
> I don't want to use it in any particular way. In that, the manual is
> 100% correct because it says nothing at all about how one might use ','
> in the way it describes operators as working. Bun I was just querying
> your statement that it is one. If you don't think it's an operator, we
> are in agreement about that.
>
OK, I will change my position and agree it is an operator. But it
cannot be used anywhere you want.
I have my own problems with PHP - for instance, it is entirely possible
to create an object without calling a constructor - a violation of OO
principles. But I work around it.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T18:59:22-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185067&th=123426#msg_185067
> On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>
>>>> > For instance a 32 bit C compiler will have different results than a 64
>>>> > bit C compiler, even if both are run on a 64 bit machine. And even
>>>> > different 32 bit C compilers can have different output. For instance,
>>>> > in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>> > within the specs
>>>>
>>>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>>>> allowed.
>>>
>>> Actually, the ANSI C spec DOES allow it. The spec sets no hard
>>> minimum or maximum for the size of any of the numeric values. C can
>>> still run on 8 bit processors, also (as in imbedded systems).
>>
>> It seems odd to be disagreeing about easily verifiable facts. ANSI C is
>> often used to refer to the first C standard (1989), in which case look
>> at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
>> standard, that's ISO/IEC 9899:2011 and the section you need is
>> "5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
>> section from each that states that the constraints imposed by limits.h
>> apply to both hosted and free-standing implementations.)
>>
>
> As I said before - I wore my ANSI C standard out and tossed it quite a
> while back. But even then it did not specify a minimum of 16 bits for
> an integer. There are still 8 bit processors and compilers out there.
>
>>>> > (which only states the length of an int is >= the
>>>> > length of a short, and <= the length of a long). So it is entirely
>>>> > possible one C compiler will have a 16 bit int, while another has a 32
>>>> > bit int. And both are within the C spec.
>>>>
>>>> Yes, but the language gives minimum guarantees which can be used to
>>>> permit code to be ported. It also (often) explicitly says where there
>>>> is no guarantee. For example, shifting right by the width of the type
>>>> being shifted is explicitly "undefined". It's useful to know that,
>>>> because you can simply avoid the situation in the first place. That's
>>>> simpler that testing it, seeing that it does what you expect, and then
>>>> finding that it fails on some other hardware.
>>>
>>> The only minimum is that an int must not be smaller than a short.
>>
>> No, there are others -- in particular, a minimum range of representable
>> values for each of the standard integer types. For int it is from
>> -32767 to +32767.
>>
>
> Then please tell me how an 8 bit compiler can be ANSI Standard? There
> are some out there. It's been a while since I did any work on one, but
> I know of several embedded systems which are still in use (and being
> updated).
It's not necessarily impossible to implement 16bit operations on an 8bit
machine. I did this long ago on a 6510, and actually it was rather simple.
> I have my own problems with PHP - for instance, it is entirely possible
> to create an object without calling a constructor - a violation of OO
> principles. But I work around it.
How is it possible to create an object without its constructor (if
defined) being called?
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T19:19:48-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185071&th=123426#msg_185071
> Jerry Stuckle wrote:
>> I have my own problems with PHP - for instance, it is entirely possible
>> to create an object without calling a constructor - a violation of OO
>> principles. But I work around it.
>
> How is it possible to create an object without its constructor (if
> defined) being called?
Implicitly: Call a factory method instead (which is neither “a violation of
OO principles” nor PHP-specific).
This can be useful. As you may recall, recently we discussed thread-safe
date formatting in de.comp.lang.php; I suggested the intl extension:
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee]]>Thomas 'PointedEars' 2014-02-25T19:43:53-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185072&th=123426#msg_185072
> Christoph Michael Becker wrote:
>
>> Furthermore I was trying to stress my (resp. Ben's) point, that a comma
>> is not always an operator, even if a language defines a comma operator.
>
> No disagreement there. However, strange as it may seem, without proof to
> the contrary “,” *is* an operator in PHP. That it is one is not negated by
> its being of limited use (which contradicts the manual; we may assume that
> it was intended to work like in C/C++/ECMAScript, but was never implemented
> this way; a documentation bug should be filed).
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T20:36:36-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185075&th=123426#msg_185075
> Jerry Stuckle wrote:
>
>> On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>>> > Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> >
>>>> >> For instance a 32 bit C compiler will have different results than a 64
>>>> >> bit C compiler, even if both are run on a 64 bit machine. And even
>>>> >> different 32 bit C compilers can have different output. For instance,
>>>> >> in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>> >> within the specs
>>>> >
>>>> > No, C does no permit int to be less that 16 bits wide -- 8 is not
>>>> > allowed.
>>>>
>>>> Actually, the ANSI C spec DOES allow it. The spec sets no hard
>>>> minimum or maximum for the size of any of the numeric values. C can
>>>> still run on 8 bit processors, also (as in imbedded systems).
>>>
>>> It seems odd to be disagreeing about easily verifiable facts. ANSI C is
>>> often used to refer to the first C standard (1989), in which case look
>>> at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
>>> standard, that's ISO/IEC 9899:2011 and the section you need is
>>> "5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
>>> section from each that states that the constraints imposed by limits.h
>>> apply to both hosted and free-standing implementations.)
>>>
>>
>> As I said before - I wore my ANSI C standard out and tossed it quite a
>> while back. But even then it did not specify a minimum of 16 bits for
>> an integer. There are still 8 bit processors and compilers out there.
>>
>>>> >> (which only states the length of an int is >= the
>>>> >> length of a short, and <= the length of a long). So it is entirely
>>>> >> possible one C compiler will have a 16 bit int, while another has a 32
>>>> >> bit int. And both are within the C spec.
>>>> >
>>>> > Yes, but the language gives minimum guarantees which can be used to
>>>> > permit code to be ported. It also (often) explicitly says where there
>>>> > is no guarantee. For example, shifting right by the width of the type
>>>> > being shifted is explicitly "undefined". It's useful to know that,
>>>> > because you can simply avoid the situation in the first place. That's
>>>> > simpler that testing it, seeing that it does what you expect, and then
>>>> > finding that it fails on some other hardware.
>>>>
>>>> The only minimum is that an int must not be smaller than a short.
>>>
>>> No, there are others -- in particular, a minimum range of representable
>>> values for each of the standard integer types. For int it is from
>>> -32767 to +32767.
>>>
>>
>> Then please tell me how an 8 bit compiler can be ANSI Standard? There
>> are some out there. It's been a while since I did any work on one, but
>> I know of several embedded systems which are still in use (and being
>> updated).
>
> It's not necessarily impossible to implement 16bit operations on an 8bit
> machine. I did this long ago on a 6510, and actually it was rather simple.
>
>> I have my own problems with PHP - for instance, it is entirely possible
>> to create an object without calling a constructor - a violation of OO
>> principles. But I work around it.
>
> How is it possible to create an object without its constructor (if
> defined) being called?
>
Load the object from the $_SESSION. The constructor will not be called.
However, the constructor is called when the original object was created,
and the destructor called when the original object goes out of scope.
The destructor is also called when the object loaded from the $_SESSION
goes out of scope.
The result is one constructor call and two destructor calls. A
violation of OO principles.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T21:01:20-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185074&th=123426#msg_185074
> Christoph Michael Becker wrote:
>
>> Jerry Stuckle wrote:
>>> I have my own problems with PHP - for instance, it is entirely possible
>>> to create an object without calling a constructor - a violation of OO
>>> principles. But I work around it.
>>
>> How is it possible to create an object without its constructor (if
>> defined) being called?
>
> Implicitly: Call a factory method instead (which is neither “a violation of
> OO principles” nor PHP-specific).
>
The constructor is still being called. I am talking about a case where
the constructor is NEVER called.
> This can be useful. As you may recall, recently we discussed thread-safe
> date formatting in de.comp.lang.php; I suggested the intl extension:
>
> $ php -r 'echo IntlDateFormatter::create("hi@calendar=BUDDHIST",
> IntlDateFormatter::FULL, IntlDateFormatter::LONG)->format(mktime(1, 2, 3, 4,
> 5, 2006)) . "\n";'
> बुधवार, 5 अप्रैल ईस्वी2006 को 1:02:03 पूर्वाह्न GMT+2
>
>
> PointedEars
>
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T21:02:03-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185078&th=123426#msg_185078
jstucklex@attglobal.net> writes:
> On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>>> > Documentation indicates what you CAN do - not what you CAN'T do. This
>>>> > is true of languages, databases, spreadsheets and about anything else
>>>> > around.
>>>>
>>>> What can you do with the ',' operator? From the PHP documentation:
>>>
>>> Where in the PHP manual does it say ',' is an operator?
>>
>> "A full list of PHP operators follows in the section Operator
>> Precedence." (which is the section immediately following)
>>
>> That list includes ',' as you yourself stated:
>>
>> "It is an operator, as indicated by its appearance in the table of
>> operators. Operators are not limited to +-*/.".
>>
>> But if that is no longer your position, then we are in agreement.
>>
>
> OK, it does show up in the operator precedence table. But it also
> says "many uses". It doesn't define those uses in the table; it
> doesn't tell you what you can't do.
Nor what you can do. The manual shows all sorts of places where commas
are used but none of the fit the description of an operator as given
else where in the manual.
>
>> <snip>
>>>> As to your general point, the C language standard is an excellent
>>>> example of documentation that says both what you can do and what you
>>>> can't do.
<snip>
>>> No, the C specification does NOT say what you cannot do.
<snip>
>> How many examples would you like? For example, the C standard gives a
>> grammar for expressions and then, for each operator, it gives
>> constraints on that general form. The grammar permits 1 = 1, but the
>> constraints on the = operator state that the expression on the left hand
>> side must be a modifiable lvalue. The upshot is that you can tell what
>> forms of expression are and are not permitted. In particular, C does
>> not permit (cond ? a : b) = expr; but C++ does.
>
> Exactly. It tells you what you CAN do. It does not tell you what you
> cannot do.
We could waste a lot of time going back and forth about what is a
statement about what can be done, and what is a statement about what
can't be done. The long and the sort of it is that PHP has restrictions
on how some operators can be used which are not documented. That, in
your interpretation of things, means that the manual fails to tell you
what you *can* do. According to my view, it fails to tell you what you
can't do. The effect is the same -- undocumented cases.
<snip>
>>>> > [...] For instance,
>>>> > in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>> > within the specs
>>>>
>>>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>>>> allowed.
>>>
>>> Actually, the ANSI C spec DOES allow it. The spec sets no hard
>>> minimum or maximum for the size of any of the numeric values. C can
>>> still run on 8 bit processors, also (as in imbedded systems).
>>
>> It seems odd to be disagreeing about easily verifiable facts. ANSI C is
>> often used to refer to the first C standard (1989), in which case look
>> at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
>> standard, that's ISO/IEC 9899:2011 and the section you need is
>> "5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
>> section from each that states that the constraints imposed by limits.h
>> apply to both hosted and free-standing implementations.)
>
> As I said before - I wore my ANSI C standard out and tossed it quite a
> while back. But even then it did not specify a minimum of 16 bits for
> an integer. There are still 8 bit processors and compilers out there.
I gave a reference to the relevant section, and I quoted (below) the
minimum rage that was specified. It been the same from the very first
ANSI standard to the latest ISO standard. The copy you thew out should
have that text just like every other copy. I don't see what more I can
do.
<snip>
>>>> Yes, but the language gives minimum guarantees which can be used to
>>>> permit code to be ported.
<snip>
>>> The only minimum is that an int must not be smaller than a short.
>>
>> No, there are others -- in particular, a minimum range of representable
>> values for each of the standard integer types. For int it is from
>> -32767 to +32767.
>
> Then please tell me how an 8 bit compiler can be ANSI Standard?
By implementing 16-bit ints (or wider) either directly by the code
generator or by calling functions. But the situation is worse than you
think. Every version of the C standard has required that long int have
at least 32 bits. A conforming compiler on an 8-bit processor must
implement a 32-bit integer type as well.
<snip>
>>>> > The PHP doc shows you what combinations are permitted. You are asking
>>>> > about what is NOT permitted.
>>>>
>>>> Yes, because that is part of the specification of the language. Aren't
>>>> you curious to know what expression forms are permitted on the left of
>>>> an assignment? Would you not find a grammar for PHP to be a useful part
>>>> of the documentation? These thing seem unexceptional to me.
>>>
>>> No, the specification of a language states only what is allowed. For
>>> instance, the C++ spec specifies which operators may be overridden.
>>> It does NOT specify that the '.' operator may not be overridden.
>>
>> Are you just saying wrong things to wind me up? Section 13.5
>> "Overloaded operators" of the current C++ standard says:
>>
>> "The following operators cannot be overloaded:
>> . .* :: ?:"
>>
>> Similar wording exists in the 1998 and 2003 standards.
>
> That has changed in the standard, then. It used to not specify those
> operators which cannot be overloaded.
The wording is in every version of the C++ standard that I have seen,
and it even predates the standard. My copy of Ellis and Stroustrup's
"The Annotated C++ Reference Manual" (1990) has exactly the same wording
on page 330.
<snip>
> If you want to produce a "rigorous standard", you are free to do
> so. But standards are mainly for compiler developers; since there is
> only one, I don't see a need for it (and I doubt ZEND would pay any
> attention to it, anyway).
I am sure they wouldn't. PHP is (to a first approximation) a single
implementation language, and so the source code for that implementation
is the final reference manual. That's how it is possible to be sure
that, at the moment, you can't use ',' as an operator in a general
expression. You can scan the grammar to see all the places where a
comma is permitted and (pretty much) exactly what it does in all those
cases.
>> <snip>
>>> Please show where in the manual it shows you can use the ',' operator
>>> like you want.
>>
>> I don't want to use it in any particular way. In that, the manual is
>> 100% correct because it says nothing at all about how one might use ','
>> in the way it describes operators as working. Bun I was just querying
>> your statement that it is one. If you don't think it's an operator, we
>> are in agreement about that.
>
> OK, I will change my position and agree it is an operator. But it
> cannot be used anywhere you want.
I can't follow this. But really, does it matter one iota if it has one
that you can't use (except in few specially documented places) or if it
doesn't have one at all?
--
Ben.]]>Ben Bacarisse2014-02-25T21:08:11-00:00Object constructors/destructors (was: Operator precedence)
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185079&th=123426#msg_185079
> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> I have my own problems with PHP - for instance, it is entirely possible
>>> to create an object without calling a constructor - a violation of OO
>>> principles. But I work around it.
>>
>> How is it possible to create an object without its constructor (if
>> defined) being called?
>>
>
> Load the object from the $_SESSION. The constructor will not be called.
>
> However, the constructor is called when the original object was created,
> and the destructor called when the original object goes out of scope.
> The destructor is also called when the object loaded from the $_SESSION
> goes out of scope.
>
> The result is one constructor call and two destructor calls. A
> violation of OO principles.
Um, I'm not sure whether this is a violation of OOP principles. Storing
an object in the session requires serialization of the object, what is
somewhat comparable to cloning an object. So actually, you're not
working with the *same* object.
Anyway, you can work around these issues by using the magic methods
__sleep() and __wakeup(), as you probably know. :)
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T21:19:13-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185080&th=123426#msg_185080
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> If you want to produce a "rigorous standard", you are free to do
>> so. But standards are mainly for compiler developers; since there is
>> only one, I don't see a need for it (and I doubt ZEND would pay any
>> attention to it, anyway).
>
> I am sure they wouldn't. PHP is (to a first approximation) a single
> implementation language, and so the source code for that implementation
> is the final reference manual. That's how it is possible to be sure
> that, at the moment, you can't use ',' as an operator in a general
> expression. You can scan the grammar to see all the places where a
> comma is permitted and (pretty much) exactly what it does in all those
> cases.
There is at least one other important implementation of PHP, namely
HHVM[1], so I wouldn't call PHP a single implementation language. IMHO
it would be wise to specify the language formally, before
implementations may drift apart.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T21:29:59-00:00Re: Object constructors/destructors
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185081&th=123426#msg_185081
> Jerry Stuckle wrote:
>
>> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> I have my own problems with PHP - for instance, it is entirely possible
>>>> to create an object without calling a constructor - a violation of OO
>>>> principles. But I work around it.
>>>
>>> How is it possible to create an object without its constructor (if
>>> defined) being called?
>>>
>>
>> Load the object from the $_SESSION. The constructor will not be called.
>>
>> However, the constructor is called when the original object was created,
>> and the destructor called when the original object goes out of scope.
>> The destructor is also called when the object loaded from the $_SESSION
>> goes out of scope.
>>
>> The result is one constructor call and two destructor calls. A
>> violation of OO principles.
>
> Um, I'm not sure whether this is a violation of OOP principles. Storing
> an object in the session requires serialization of the object, what is
> somewhat comparable to cloning an object. So actually, you're not
> working with the *same* object.
>
> Anyway, you can work around these issues by using the magic methods
> __sleep() and __wakeup(), as you probably know. :)
>
Yes, it is a violation. When the script starts, the object is
serialized in the $_SESSION. But it does not exist in the script.
Creating it requires a constructor call. OO principles require exactly
one constructor call and one destructor call for every object created.
Note these may be explicit or implicit, and the functions may be noops,
but the calls must still be made. That is not the case here; you get
one constructor call and two destructor calls.
I know of no other OO language which would allow this.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T21:32:34-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185082&th=123426#msg_185082
PointedEars@web.de> wrote:
> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> […] Expressions are built from operators, but is ',' an operator
>>>> in PHP? It appears in the operator precedence table but it isn't an
>>>> operator in an sense that would normally be understood by someone
>>>> familiar with these terms.
>>>
>>> ECMAScript has a “Comma Operator”, too.
>>
>> But my point was the PHP doesn't have one --
>
> But it does:
>
> for ($i = 0, $j = 42; $i < $j; ++$i);
> ^
The comma serves as a separator here, not an operator. It's just
separating items in a list in the same way you do with arguments in a
function call. I think the reason it's in the operator table is just to
clarify that expressions in a list don't need to be bracketed since all
real operators bind more tightly than "," (as you'd expect).
Formally, an operator is just a function which uses infix notation for
its arguments, ie. semantically a OP b = OP(a,b). In fact, some
languages let you define your own operators in exactly the same way as
you do functions. So things like , and ; are not operators (in PHP
anyway) since unlike stuff such as + or > they don't denote functions
which operate on their operands.
The only reason we have operators at all in programming languages is
because the infix notation is familiar and saves us from the LISP hell
of endlessly bracketing everything. Most people find a+b/c easier on
the eye than +(a,/(b,c)). The drawback of the infix notation is it
creates ambiguities that have to be resolved in the language definition
e.g. by assigning a precedence to every operator, or stipulating linear
evaluation, or requiring that every expression containing more than one
operator be bracketed.
This brings us back to what started this thread, namely that in order to
understand the meaning of a PHP expression you need a formal definition
of how expressions are evaluated, including precedence rules. The
existence of a "but..." in the operator precedence documentation subtley
reveals that the formal definition of a PHP expression is not what we
might have thought it to be, as has since been clarified by those
posters who have looked at the source code.
Looking again at the Language Reference page, "Expressions", I think my
original comment that it does not define what an expression is (for
Jerry's benefit I should say "what a PHP expression is"!) still stands.
It gives several examples but falls short of a formal definition which
would tell us whether or not we can use constructions like !$a && $a =
42.]]>GS2014-02-25T21:45:35-00:00Re: Object constructors/destructors
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185084&th=123426#msg_185084
> On 2/25/2014 4:19 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>> > I have my own problems with PHP - for instance, it is entirely
>>>> > possible
>>>> > to create an object without calling a constructor - a violation of OO
>>>> > principles. But I work around it.
>>>>
>>>> How is it possible to create an object without its constructor (if
>>>> defined) being called?
>>>>
>>>
>>> Load the object from the $_SESSION. The constructor will not be called.
>>>
>>> However, the constructor is called when the original object was created,
>>> and the destructor called when the original object goes out of scope.
>>> The destructor is also called when the object loaded from the $_SESSION
>>> goes out of scope.
>>>
>>> The result is one constructor call and two destructor calls. A
>>> violation of OO principles.
>>
>> Um, I'm not sure whether this is a violation of OOP principles. Storing
>> an object in the session requires serialization of the object, what is
>> somewhat comparable to cloning an object. So actually, you're not
>> working with the *same* object.
>>
>> Anyway, you can work around these issues by using the magic methods
>> __sleep() and __wakeup(), as you probably know. :)
>>
>
> Yes, it is a violation. When the script starts, the object is
> serialized in the $_SESSION. But it does not exist in the script.
> Creating it requires a constructor call.
It requires the object to be created in memory somehow, but the defined
constructor function is not called in this case.
> OO principles require exactly
> one constructor call and one destructor call for every object created.
> Note these may be explicit or implicit, and the functions may be noops,
> but the calls must still be made.
When you're cloning an object, its constructor will not be called either.
> That is not the case here; you get
> one constructor call and two destructor calls.
I firmly believe that it wouldn't make sense to call a (user-defined)
constructor when unserializing or cloning an object. A constructor
usually serves to initialize an object -- what already had happened in
both cases.
> I know of no other OO language which would allow this.
Others may.
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T21:55:16-00:00Re: Object constructors/destructors
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185085&th=123426#msg_185085
> Jerry Stuckle wrote:
>
>> On 2/25/2014 4:19 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>>>> > Jerry Stuckle wrote:
>>>> >
>>>> >> I have my own problems with PHP - for instance, it is entirely
>>>> >> possible
>>>> >> to create an object without calling a constructor - a violation of OO
>>>> >> principles. But I work around it.
>>>> >
>>>> > How is it possible to create an object without its constructor (if
>>>> > defined) being called?
>>>> >
>>>>
>>>> Load the object from the $_SESSION. The constructor will not be called.
>>>>
>>>> However, the constructor is called when the original object was created,
>>>> and the destructor called when the original object goes out of scope.
>>>> The destructor is also called when the object loaded from the $_SESSION
>>>> goes out of scope.
>>>>
>>>> The result is one constructor call and two destructor calls. A
>>>> violation of OO principles.
>>>
>>> Um, I'm not sure whether this is a violation of OOP principles. Storing
>>> an object in the session requires serialization of the object, what is
>>> somewhat comparable to cloning an object. So actually, you're not
>>> working with the *same* object.
>>>
>>> Anyway, you can work around these issues by using the magic methods
>>> __sleep() and __wakeup(), as you probably know. :)
>>>
>>
>> Yes, it is a violation. When the script starts, the object is
>> serialized in the $_SESSION. But it does not exist in the script.
>> Creating it requires a constructor call.
>
> It requires the object to be created in memory somehow, but the defined
> constructor function is not called in this case.
>
Which is a violation of OO principles.
>> OO principles require exactly
>> one constructor call and one destructor call for every object created.
>> Note these may be explicit or implicit, and the functions may be noops,
>> but the calls must still be made.
>
> When you're cloning an object, its constructor will not be called either.
>
It is in every other language. For instance, in Java, clone() acts like
a copy constructor. C++ doesn't have a clone() method, but it does have
a copy constructor.
>> That is not the case here; you get
>> one constructor call and two destructor calls.
>
> I firmly believe that it wouldn't make sense to call a (user-defined)
> constructor when unserializing or cloning an object. A constructor
> usually serves to initialize an object -- what already had happened in
> both cases.
>
It makes perfect sense. Not everything is necessarily valid in the new
object. For instance, a logging object may require opening the log
file. There are many instances where a resource is no longer available
and needs to be recreated.
PHP's method is only a shallow copy. Copy constructors and the like
were created when a deep copy is required (quite often in other languages).
>> I know of no other OO language which would allow this.
>
> Others may.
>
None that I know of. Please name one.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-02-25T22:01:52-00:00Re: Operator precedence
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185089&th=123426#msg_185089
cmbecker69@arcor.de> writes:
> Ben Bacarisse wrote:
>
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> If you want to produce a "rigorous standard", you are free to do
>>> so. But standards are mainly for compiler developers; since there is
>>> only one, I don't see a need for it (and I doubt ZEND would pay any
>>> attention to it, anyway).
>>
>> I am sure they wouldn't. PHP is (to a first approximation) a single
>> implementation language, and so the source code for that implementation
>> is the final reference manual. That's how it is possible to be sure
>> that, at the moment, you can't use ',' as an operator in a general
>> expression. You can scan the grammar to see all the places where a
>> comma is permitted and (pretty much) exactly what it does in all those
>> cases.
>
> There is at least one other important implementation of PHP, namely
> HHVM[1], so I wouldn't call PHP a single implementation language. IMHO
> it would be wise to specify the language formally, before
> implementations may drift apart.
>
> [1] <http://www.hhvm.com/blog/>
Interesting, thanks. I was not aware of any other implementations.
From reading a bit of the site, it seems that the objective is full
agreement with the Zend implementation, so, for the moment, there is
still a single implementation that is the ultimate reference. Any
disagreement in results will be seen as a bug for now (and quite a few
such bugs are listed).
--
Ben.]]>Ben Bacarisse2014-02-25T23:15:04-00:00Re: Object constructors/destructors
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=185092&th=123426#msg_185092
> On 2/25/2014 4:55 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> On 2/25/2014 4:19 PM, Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>>
>>>> > On 2/25/2014 2:19 PM, Christoph Michael Becker wrote:
>>>> >> Jerry Stuckle wrote:
>>>> >>
>>>> >>> I have my own problems with PHP - for instance, it is entirely
>>>> >>> possible
>>>> >>> to create an object without calling a constructor - a violation
>>>> >>> of OO
>>>> >>> principles. But I work around it.
>>>> >>
>>>> >> How is it possible to create an object without its constructor (if
>>>> >> defined) being called?
>>>> >>
>>>> >
>>>> > Load the object from the $_SESSION. The constructor will not be
>>>> > called.
>>>> >
>>>> > However, the constructor is called when the original object was
>>>> > created,
>>>> > and the destructor called when the original object goes out of scope.
>>>> > The destructor is also called when the object loaded from the
>>>> > $_SESSION
>>>> > goes out of scope.
>>>> >
>>>> > The result is one constructor call and two destructor calls. A
>>>> > violation of OO principles.
>>>>
>>>> Um, I'm not sure whether this is a violation of OOP principles.
>>>> Storing
>>>> an object in the session requires serialization of the object, what is
>>>> somewhat comparable to cloning an object. So actually, you're not
>>>> working with the *same* object.
>>>>
>>>> Anyway, you can work around these issues by using the magic methods
>>>> __sleep() and __wakeup(), as you probably know. :)
>>>>
>>>
>>> Yes, it is a violation. When the script starts, the object is
>>> serialized in the $_SESSION. But it does not exist in the script.
>>> Creating it requires a constructor call.
>>
>> It requires the object to be created in memory somehow, but the defined
>> constructor function is not called in this case.
>>
>
> Which is a violation of OO principles.
>
>>> OO principles require exactly
>>> one constructor call and one destructor call for every object created.
>>> Note these may be explicit or implicit, and the functions may be noops,
>>> but the calls must still be made.
>>
>> When you're cloning an object, its constructor will not be called either.
>>
>
> It is in every other language. For instance, in Java, clone() acts like
> a copy constructor. C++ doesn't have a clone() method, but it does have
> a copy constructor.
Isn't the copy constructor called on other occassions as the normal
constructor?
If so, then PHP doesn't handle that too different. While
__constructor() would be the counterpart of a normal constructor,
__clone() would be the counterpart of a copy constructor.
>>> That is not the case here; you get
>>> one constructor call and two destructor calls.
>>
>> I firmly believe that it wouldn't make sense to call a (user-defined)
>> constructor when unserializing or cloning an object. A constructor
>> usually serves to initialize an object -- what already had happened in
>> both cases.
>>
>
> It makes perfect sense. Not everything is necessarily valid in the new
> object. For instance, a logging object may require opening the log
> file. There are many instances where a resource is no longer available
> and needs to be recreated.
Therefore there are __sleep() and wakeup(). In __sleep() you can close
the log file (if it's still open), and in __wakeup() you can open it again.
Anyway, consider the following snippet:
<?php
class Foo {
function __construct() {
$this->bar = 'foo';
}
function setBar($bar) {
$this->bar = $bar;
}
}
$foo = new Foo();
$foo->setBar('bar');
$bar = unserialize(serialize($foo));
echo $bar->bar;
What output would you expect?
> PHP's method is only a shallow copy. Copy constructors and the like
> were created when a deep copy is required (quite often in other languages).
You can force a deep copy yourself by respectively defining __clone().
>>> I know of no other OO language which would allow this.
>>
>> Others may.
>>
>
> None that I know of. Please name one.
Obviously, I was too terse here. I meant: "I can't name one, but others
may be able to name one."
--
Christoph M. Becker]]>Christoph Michael Bec2014-02-25T23:18:40-00:00