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 #185060 is a reply to message #185055] Tue, 25 February 2014 16:56 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/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.

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

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

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

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

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

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

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

--
Ben.

Report message to a moderator

[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: Wed Nov 27 18:13:13 GMT 2024

Total time taken to generate the page: 0.04018 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software