| Re: Operator precedence [message #185055 is a reply to message #185053] |
Tue, 25 February 2014 04:47   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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?
> An operator is something that takes one or more values (or
> expressions, in programming jargon) and yields another value (so that
> the construction itself becomes an expression).
>
> I can't see any usage of ',' that matches this definition. By the
> manual's own definition, ',' in not an operator in PHP.
>
> 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.
>>> <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.
>
> So you think my example is of something that can't be done and that is
> why you can't tell what the code done by
If it's not documented that you can do it, you can try it and see if it
works. But beware that undocumented "features" may or may not act the
same way in the next release.
>>
>>> 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
>
> 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).
>> (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.
>> And on 64 bit hardware, an int could be 64 bits long.
>
> More surprisingly, so could a char!
>
>>> <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.
>
> 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.
> <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.
>
> Well, I'd rather not. PHP has a more special cases than other languages
> I've used, so it would be harder than for those. But I am surprised
> that that you think it's so unreasonable to expect at least a moderately
> rigorous definition of what is and is not permitted. As I said before,
> it seems perfect reasonable to me. Even a grammar for the language
> (surely not that hard) would have eliminated the OP's question from the
> get go.
>
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?).
>>>> 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".
>
> I don't recognise any of that.
>
Why not? It's exactly what you are saying.
> I was making a sound technical point in reply to you: that PHP does not
> have a ',' operator except in some sort of literalist sense: the manual
> says it does, so it does, despite the fact that its meaning is undefined
> and you can't use it in expressions to make bigger expressions.
>
I never claimed it does. Where in the manual does it say you can use
the ',' operator like you want?
> Your counter argument seems to be that the manual is not obliged to
> document what you can't do. I disagree about that, but even if this is
> granted, it is surely a mistake to list ',' as an operator when it
> clearly isn't.
>
> <snip>
>
Exactly. The manual is obliged to only document what you can do. That
is true for any language.
Please show where in the manual it shows you can use the ',' operator
like you want.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]