| Re: Operator precedence [message #185065 is a reply to message #185060] |
Tue, 25 February 2014 18:59   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 2/25/2014 11:56 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>
>> On 2/24/2014 11:32 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>>>
>>>> On 2/24/2014 4:23 PM, Ben Bacarisse wrote:
>>>> > Jerry Stuckle <jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]