Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12889 > unrolled thread

Operator precedence

Back to article view | Back to comp.lang.php

Contents

  Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 18:03 +0100
    Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-23 19:42 +0000
      Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-23 21:23 +0100
      Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 16:34 -0500
        Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-23 18:36 -0500
          Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-23 21:09 -0500
            Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 04:49 +0000
              Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:56 +0100
                Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 17:38 +0100
                Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:25 +0000
                  Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 00:38 +0100
                    Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:07 +0100
                      Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 01:37 +0100
                        Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 02:12 +0100
                          Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 03:29 +0100
                            Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:41 +0100
                              Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 19:55 +0100
                                Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 21:36 +0100
                    Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 03:08 +0000
                      Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 04:17 +0100
                        Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:45 +0000
                    Re: Operator precedence GS <nomail@nospam.org.invalid> - 2014-02-25 21:45 +0000
              Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 07:00 -0500
                Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 18:11 +0100
                  Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 14:27 -0500
                    Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:25 +0100
                      Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 20:40 -0500
                Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-24 21:23 +0000
                  Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 16:45 -0500
                    Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 04:32 +0000
                      Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:47 -0500
                        Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 16:56 +0000
                          Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 13:59 -0500
                            Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 20:19 +0100
                              Re: Operator precedence Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:43 +0100
                                Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:02 -0500
                              Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:01 -0500
                                Object constructors/destructors (was: Operator precedence) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:19 +0100
                                  Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:32 -0500
                                    Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:55 +0100
                                      Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 17:01 -0500
                                        Re: Object constructors/destructors Adam Harvey <usenet@adamharvey.name> - 2014-02-25 23:22 +0000
                                          Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:10 -0500
                                            Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 21:10 +0100
                                              Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 16:01 -0500
                                                Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 22:59 +0100
                                                  Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 17:19 -0500
                                                    Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 23:39 +0100
                                                      Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:30 -0500
                                                        Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-27 18:28 +0100
                                                          Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:09 -0500
                                                            Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 14:52 +0100
                                                              Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 09:08 -0500
                                                                Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-28 16:52 +0100
                                                                  Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-28 11:03 -0500
                                              Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 01:00 +0100
                                                Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 22:39 -0500
                                                  Re: Object constructors/destructors Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 18:29 +0100
                                                    Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:14 -0500
                                        Re: Object constructors/destructors Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 00:18 +0100
                                          Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 21:08 -0500
                                    Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 07:50 -0500
                                      Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 08:44 -0500
                                        Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-02-26 23:49 -0500
                                          Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 08:25 -0500
                                            Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-01 12:56 -0500
                                              Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:22 -0500
                                                Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 14:28 -0500
                                                  Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:42 -0500
                                                    Re: Object constructors/destructors Richard Damon <Richard@Damon-Family.org> - 2014-03-02 17:14 -0500
                                                      Re: Object constructors/destructors Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 17:48 -0500
                                                        Re: Object constructors/destructors Tim Streater <timstreater@greenbee.net> - 2014-03-02 23:05 +0000
                            Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 21:08 +0000
                              Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:29 +0100
                                Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-25 23:15 +0000
                Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-02-24 22:41 -0500
                  Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 23:59 -0500
                    Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-01 13:39 -0500
                      Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-01 14:29 -0500
                        Re: Operator precedence Richard Damon <Richard@Damon-Family.org> - 2014-03-02 15:22 -0500
                          Re: Operator precedence Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-02 15:49 -0500
                  Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 19:15 +0100
    Re: Operator precedence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-23 20:56 +0000
      Re: Operator precedence Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 14:28 +0100

Page 1 of 5  [1] 2 3 4 5  Next page →

#12889 — Operator precedence

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>

-- 
Christoph M. Becker

[toc] | [next] | [standalone]

#12894

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.

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?)

[toc] | [prev] | [next] | [standalone]

#12897

GS wrote:

> 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):

statement ->
expr ';' ->
expr T_BOOLEAN_AND expr ';' ->
'!' variable T_BOOLEAN_AND variable '=' expr ';'

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

[toc] | [prev] | [next] | [standalone]

#12906

On 2/23/2014 2:42 PM, GS wrote:
> 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
==================

[toc] | [prev] | [next] | [standalone]

#12911

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).

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.

[toc] | [prev] | [next] | [standalone]

#12912

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.

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
==================

[toc] | [prev] | [next] | [standalone]

#12913

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.

<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.

[toc] | [prev] | [next] | [standalone]

#12914

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>


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#12919

Thomas 'PointedEars' Lahn wrote:

> 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.

[1] <http://www.php.net/manual/en/language.operators.precedence.php>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12927

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 -- not in any normal sense of
the word.  ECMAScript really does have one (like C and C++ do).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#12930

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);
             ^

> 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.)

[toc] | [prev] | [next] | [standalone]

#12932

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).

>> 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)?

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>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12936

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, 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;

I am aware of that.
 
>>> 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;
  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;

int main() {
  cout << (42, 23) << endl;
  return 0;
}

$ 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>

[toc] | [prev] | [next] | [standalone]

#12938

Thomas 'PointedEars' Lahn wrote:

> 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:

That's my point. :)

[1] <http://www.cs.man.ac.uk/~pjj/bnf/c_syntax.bnf>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12941

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.  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).

[toc] | [prev] | [next] | [standalone]

#12961

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,
>>
>> 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

[toc] | [prev] | [next] | [standalone]

#12962

Christoph Michael Becker wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#12970

Thomas 'PointedEars' Lahn wrote:

> 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).

Done.[1]

[1] <https://bugs.php.net/bug.php?id=66772>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12947

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);

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.

[toc] | [prev] | [next] | [standalone]

#12948

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.
> 
> 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>

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.php

csiph-web