| Re: Operator precedence [message #185053 is a reply to message #185030] |
Tue, 25 February 2014 04:32   |
Ben Bacarisse
Messages: 82
Registered: November 2013
Karma:
|
Member |
|
|
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:
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.
>> <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
>
>> 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.
> (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.
> 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.
<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.
>>> 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.
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.
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>
--
Ben.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]