FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Operator precedence
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Operator precedence [message #185078 is a reply to message #185065] Tue, 25 February 2014 21:08 Go to previous messageGo to previous message
Ben Bacarisse is currently offline  Ben Bacarisse
Messages: 82
Registered: November 2013
Karma:
Member
Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:

> 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:
<snip>
>>>> > Documentation indicates what you CAN do - not what you CAN'T do. This
>>>> > is true of languages, databases, spreadsheets and about anything else
>>>> > around.
>>>>
>>>> What can you do with the ',' operator? From the PHP documentation:
>>>
>>> Where in the PHP manual does it say ',' is an operator?
>>
>> "A full list of PHP operators follows in the section Operator
>> Precedence." (which is the section immediately following)
>>
>> That list includes ',' as you yourself stated:
>>
>> "It is an operator, as indicated by its appearance in the table of
>> operators. Operators are not limited to +-*/.".
>>
>> But if that is no longer your position, then we are in agreement.
>>
>
> OK, it does show up in the operator precedence table. But it also
> says "many uses". It doesn't define those uses in the table; it
> doesn't tell you what you can't do.

Nor what you can do. The manual shows all sorts of places where commas
are used but none of the fit the description of an operator as given
else where in the manual.
>
>> <snip>
>>>> As to your general point, the C language standard is an excellent
>>>> example of documentation that says both what you can do and what you
>>>> can't do.
<snip>
>>> No, the C specification does NOT say what you cannot do.
<snip>
>> How many examples would you like? For example, the C standard gives a
>> grammar for expressions and then, for each operator, it gives
>> constraints on that general form. The grammar permits 1 = 1, but the
>> constraints on the = operator state that the expression on the left hand
>> side must be a modifiable lvalue. The upshot is that you can tell what
>> forms of expression are and are not permitted. In particular, C does
>> not permit (cond ? a : b) = expr; but C++ does.
>
> Exactly. It tells you what you CAN do. It does not tell you what you
> cannot do.

We could waste a lot of time going back and forth about what is a
statement about what can be done, and what is a statement about what
can't be done. The long and the sort of it is that PHP has restrictions
on how some operators can be used which are not documented. That, in
your interpretation of things, means that the manual fails to tell you
what you *can* do. According to my view, it fails to tell you what you
can't do. The effect is the same -- undocumented cases.

<snip>
>>>> > [...] For instance,
>>>> > in a 32 bit C compiler, an int can be 8, 16, or 32 bits long - all
>>>> > within the specs
>>>>
>>>> No, C does no permit int to be less that 16 bits wide -- 8 is not
>>>> allowed.
>>>
>>> Actually, the ANSI C spec DOES allow it. The spec sets no hard
>>> minimum or maximum for the size of any of the numeric values. C can
>>> still run on 8 bit processors, also (as in imbedded systems).
>>
>> It seems odd to be disagreeing about easily verifiable facts. ANSI C is
>> often used to refer to the first C standard (1989), in which case look
>> at section 2.2.4.2 "Numerical limits". If you mean the current ANSI
>> standard, that's ISO/IEC 9899:2011 and the section you need is
>> "5.2.4.2.1 Sizes of integer types <limits.h>". (You also need the
>> section from each that states that the constraints imposed by limits.h
>> apply to both hosted and free-standing implementations.)
>
> As I said before - I wore my ANSI C standard out and tossed it quite a
> while back. But even then it did not specify a minimum of 16 bits for
> an integer. There are still 8 bit processors and compilers out there.

I gave a reference to the relevant section, and I quoted (below) the
minimum rage that was specified. It been the same from the very first
ANSI standard to the latest ISO standard. The copy you thew out should
have that text just like every other copy. I don't see what more I can
do.

<snip>
>>>> Yes, but the language gives minimum guarantees which can be used to
>>>> permit code to be ported.
<snip>
>>> The only minimum is that an int must not be smaller than a short.
>>
>> No, there are others -- in particular, a minimum range of representable
>> values for each of the standard integer types. For int it is from
>> -32767 to +32767.
>
> Then please tell me how an 8 bit compiler can be ANSI Standard?

By implementing 16-bit ints (or wider) either directly by the code
generator or by calling functions. But the situation is worse than you
think. Every version of the C standard has required that long int have
at least 32 bits. A conforming compiler on an 8-bit processor must
implement a 32-bit integer type as well.

<snip>
>>>> > The PHP doc shows you what combinations are permitted. You are asking
>>>> > about what is NOT permitted.
>>>>
>>>> Yes, because that is part of the specification of the language. Aren't
>>>> you curious to know what expression forms are permitted on the left of
>>>> an assignment? Would you not find a grammar for PHP to be a useful part
>>>> of the documentation? These thing seem unexceptional to me.
>>>
>>> No, the specification of a language states only what is allowed. For
>>> instance, the C++ spec specifies which operators may be overridden.
>>> It does NOT specify that the '.' operator may not be overridden.
>>
>> Are you just saying wrong things to wind me up? Section 13.5
>> "Overloaded operators" of the current C++ standard says:
>>
>> "The following operators cannot be overloaded:
>> . .* :: ?:"
>>
>> Similar wording exists in the 1998 and 2003 standards.
>
> That has changed in the standard, then. It used to not specify those
> operators which cannot be overloaded.

The wording is in every version of the C++ standard that I have seen,
and it even predates the standard. My copy of Ellis and Stroustrup's
"The Annotated C++ Reference Manual" (1990) has exactly the same wording
on page 330.

<snip>
> If you want to produce a "rigorous standard", you are free to do
> so. But standards are mainly for compiler developers; since there is
> only one, I don't see a need for it (and I doubt ZEND would pay any
> attention to it, anyway).

I am sure they wouldn't. PHP is (to a first approximation) a single
implementation language, and so the source code for that implementation
is the final reference manual. That's how it is possible to be sure
that, at the moment, you can't use ',' as an operator in a general
expression. You can scan the grammar to see all the places where a
comma is permitted and (pretty much) exactly what it does in all those
cases.

>> <snip>
>>> Please show where in the manual it shows you can use the ',' operator
>>> like you want.
>>
>> I don't want to use it in any particular way. In that, the manual is
>> 100% correct because it says nothing at all about how one might use ','
>> in the way it describes operators as working. Bun I was just querying
>> your statement that it is one. If you don't think it's an operator, we
>> are in agreement about that.
>
> OK, I will change my position and agree it is an operator. But it
> cannot be used anywhere you want.

I can't follow this. But really, does it matter one iota if it has one
that you can't use (except in few specially documented places) or if it
doesn't have one at all?

--
Ben.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Correlating curl resources to some other object.
Next Topic: Experienced Web designer required
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri May 10 12:14:27 GMT 2024

Total time taken to generate the page: 0.04537 seconds