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

Groups > comp.lang.php > #12928

Re: Operator precedence

From Jerry Stuckle <jstucklex@attglobal.net>
Newsgroups comp.lang.php
Subject Re: Operator precedence
Date 2014-02-24 16:45 -0500
Organization A noiseless patient Spider
Message-ID <legehm$286$1@dont-email.me> (permalink)
References (3 earlier) <TBvOu.69870$bF1.64625@en-nntp-01.dc1.easynews.com> <lee9kd$hq4$1@dont-email.me> <0.914eafe42061d70d7566.20140224044930GMT.87fvn9ru79.fsf@bsb.me.uk> <lefc8a$7ki$1@dont-email.me> <0.176fb73a1430ceabf46e.20140224212342GMT.87y510qk69.fsf@bsb.me.uk>

Show all headers | View raw

On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
> 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
==================

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web