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

Groups > comp.lang.php > #12963

Re: Operator precedence

Show all headers | View raw

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

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