On Sat, Jul 20, 2013 at 1:33 AM, Sara Golemon <[email protected]> wrote:
> Your example "-$a * $a" isn't at all the same because -$a doesn't produce
> side-effects, only output.
>
It doesn't have side effects. This is true. So I retract my argument there.
>
> I never said that the compiler might magically produce differing results
> for the same input. I said that the language's definition does not declare
> a defined behavior for such expressions with combined side effects.
>
While this is very true it's also a matter of discretion, because the
language doesn't clearly define a lot of things. In fact, one can argue
that there is no language definition at all since PHP doesn't even have a
spec. Though I'm trying to take common sense into consideration and make an
exception that in this case I don't see where removing the comment of
undefined behavior is going to necessarily cause more harm than good. Since
in the case of undefined behavior people will be left to wonder (why
doesn't ever seem to print 5?) We should either elaborate on why it *might*
print 5 in a full note on that page or we should remove the comment
completely. I oppose a documentation that leaves much room for clarity.
But perhaps for me it was easier to suggest removing the comment than
trying to clarify on why the behavior is undefined.
>
> As to reverting commits. When the initial commit was made in haste during
> an active discussion, a revert is entirely appropriate and has nothing to
> do with placing one's opinion over another's. It has to do with placing
> the process of consensus building over unilateral cowboy commits.
>
Fair enough.
>
> -Sara
>
>
> On Fri, Jul 19, 2013 at 10:08 PM, Sherif Ramadan <[email protected]>wrote:
>
>>
>> Sara,
>>
>> On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon <[email protected]> wrote:
>>
>>> What's undefined isn't the relationship between preinc/postinc and add.
>>> What's undefined is the use of multiple preinc/postinc operators within a
>>> single expression
>>>
>>
>> I'm sorry but I can not find any evidence of how that is undefined. The
>> operators are right-associative, with a defined level or precedence. Their
>> operands are well defined and their return value in the expression is
>> determined by the compiler, not the parser. In this sense the compiler
>> always executes those opcodes first and returns a temporary variable.
>>
>>
>>> (preincrements in particular). Our parser grammer, as it currently
>>> stands, does have a predictable order, but that is a side-effect of
>>> implementation. The language's definition of order of resolution of
>>> multiple preinc/postinc elements within a single ticked statement is that
>>> they are undefined. And *that* is what made your *particular* change to
>>> the documentation incorrect.
>>>
>>
>> The parser grammar in general is pretty muddled, I will agree with that.
>> However, the precedence order here is well defined within the expression. I
>> can not see any condition under which the compiler will introduce
>> unpredictable order of these opcodes or their results.
>>
>>
>>>
>>> If you'd like to define behavior for: echo ++$a + 1; then that's a
>>> different matter. Defining the behavior of ++$a + $a++, however is
>>> inviting misunderstanding*.
>>>
>>> What was inappropriate, was asking for comment, receiving comment which
>>> cited an issue, then committing without discussing that issue first.
>>>
>>> -Sara
>>>
>>> * Even if, technically, either order of evaluation will result in the
>>> same answer for this contrived expression. ++$a * $a++ is a more obviously
>>> ambiguous answer for a language which explicitly does not define an order
>>> of resolution.
>>>
>>
>> By that logic we should indicate that -$a * $a is also undefined
>> behavior? I know the parser grammar is not well-defined and I'm taking this
>> fact into consideration, but here we are talking about operators which will
>> compile down into very much well-defined opcodes and have a predictable
>> order of resolution. It's quite possible that someone could introduce a
>> change later on that will cause a different result, but the likelihood of
>> that becoming a reality is slim-to-none.
>>
>> I'm not a fan of getting into cat and mouse games over these types of
>> discussions, however. I posed my opinion on this matter and I refuse to
>> overwrite someone's commit because I feel my opinion is the only one that
>> counts. I am certainly not above being wrong. I just want to be sensible.
>>
>>
>>>
>>>
>>> On Fri, Jul 19, 2013 at 9:28 PM, Yasuo Ohgaki <[email protected]>wrote:
>>>
>>>> Hi Sara,
>>>>
>>>> 2013/7/20 Sara Golemon <[email protected]>
>>>>
>>>>> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki <[email protected]>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> If there aren't comments, I'll rewrite the example.
>>>>>>
>>>>>>
>>>>>> There were comments. I explicitly told you that that the behavior is
>>>>> defined as undefined. You CHOSE to ignore that comment. You CHOSE to
>>>>> break the documentation.
>>>>>
>>>>
>>>> If there is defined precedence, arithmetic operation should follow it.
>>>> If there is exception, it should be documented.
>>>>
>>>> I don't understand why/how the arithmetic operation can be
>>>> ambiguous with defined precedence. (++ and -- are higher than +)
>>>>
>>>> $a = 1;
>>>> echo ++$a + $a++;
>>>>
>>>> should always print 4 with current PHP precedence definition.
>>>> If it does not, it's a bug in language.
>>>>
>>>> // mixing ++ and + produces undefined behavior
>>>> $a = 1;
>>>> echo ++$a + $a++; // may print 4 or 5
>>>>
>>>> I don't see any reason it became undefined.
>>>> If this kind of simple precedence is broken, how programmers write
>>>> code and/or trust the language?
>>>>
>>>> http://3v4l.org/mR4da/vld#tabs
>>>>
>>>> This site seems support PHP 4.3.0 to PHP 5.5.0 and opcode looks
>>>> fine. Am I missing something?
>>>>
>>>> If you would like to suggest use of (), it should be done differently.
>>>> IMHO.
>>>> The comment only ruins PHP's reputation as language.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Yasuo Ohgaki
>>>> [email protected]
>>>>
>>>
>>>
>>
>