Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70741 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6563 invoked from network); 19 Dec 2013 03:59:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Dec 2013 03:59:29 -0000 Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.212.176 mail-wi0-f176.google.com Received: from [209.85.212.176] ([209.85.212.176:42634] helo=mail-wi0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/04-14632-F1F62B25 for ; Wed, 18 Dec 2013 22:59:28 -0500 Received: by mail-wi0-f176.google.com with SMTP id hq4so6273284wib.15 for ; Wed, 18 Dec 2013 19:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DHuj3gIccXCK4ytSPae6FT1F/Kk453z9/NdsWDhIOPM=; b=wnJwYhv2e93Wb7tP+G2lJXClHHnwBHUrh+L7+E3XM8eOLJYsNNEBrynOYwqTqtKCbS I2LoJV+pP4o4Vfppi7IiB1ZWfcN7Ch8LdQSTBWCZTzvj9nDQHUmqdKYuFlqrZdGARtjR fRlBiVHhhogAiOYBSk0DyBng8EMBYnIjf0pdgGaJfLiCCqOb5A/3mUqeZTm/o178YKAX Qdpl5k92ozThSzGzf6kGvMvURsDIcuF8vA2MFx0LloGrLJK2h3YzgPlW0Ol+lJfR7wEp 8x2TY2b1N3r1sk7svxqogYHXPlm2faP4o+uy6HZpihOt2YlSHNa38n/Fm4x0uAyLRoiB rXSQ== MIME-Version: 1.0 X-Received: by 10.180.21.101 with SMTP id u5mr403416wie.38.1387425564660; Wed, 18 Dec 2013 19:59:24 -0800 (PST) Received: by 10.227.32.135 with HTTP; Wed, 18 Dec 2013 19:59:24 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Dec 2013 22:59:24 -0500 Message-ID: To: Tjerk Meesters Cc: Hannes Magnusson , Kris Craig , PHP Internals Content-Type: multipart/alternative; boundary=047d7bb70ca2ef1c2104eddb2f40 Subject: Re: [PHP-DEV] Re: [vote] pow-operator From: theanomaly.is@gmail.com (Sherif Ramadan) --047d7bb70ca2ef1c2104eddb2f40 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 18, 2013 at 10:17 PM, Tjerk Meesters wrote: > Hi Hannes, > > > On Thu, Dec 19, 2013 at 10:08 AM, Hannes Magnusson < > hannes.magnusson@gmail.com> wrote: > > > On Wed, Dec 18, 2013 at 6:04 PM, Tjerk Meesters > > wrote: > > > Hi Kris, > > > > > > > > > On Thu, Dec 19, 2013 at 8:35 AM, Kris Craig > > wrote: > > > > > >> > > >>> That said, if there are other reasons for voting 'no' besides > > >>> associativity, feel free to shoot me an email or discuss it on the > > list. > > >>> > > >> > > >> What did it for me was the lower precedence for the unary minus. I > > don't > > >> want to have another language that thinks a negative number squared > is a > > >> negative number. I understand and respect your reasoning as outlined > in > > >> the RFC, but this is a deal-breaker for me. > > >> > > > > > > I've had a short discussion with Anthony about this and he convinced me > > > that I was indeed wrong about my "unary minus" reasoning; therefore I > > have > > > updated the RFC to reflect that. So: > > > > > > > > > I'm a little bit confused. > > > > Are you modifying the poll, and the rfc itself, in the middle of a vote? > > > > You're right. I've made a faux pas, I shouldn't have done that. > > Sorry Kris, the change is reverted; in fact, the following documents back > up my original implementation choice: > - http://mathforum.org/library/drmath/view/53194.html > - > > http://math.stackexchange.com/questions/491933/exponent-rules-with-negative-numbers > - > > http://math.stackexchange.com/questions/68833/what-does-22-evaluate-to/68834#68834 > > If the conceptual design of php is that unary operators must bind stronger > than any binary operator, we would have to restart the vote but I'm hoping > that won't be necessary. > > I shouldn't make decisions before coffee. Apologies for the confusion! > > > > > > -Hannes > > > > > > -- > -- > Tjerk > I honestly do not think that the preference of associativity should out-weigh the benefits of this RFC (having an exponentiation operator). As covered in the discussion portion and the RFC, the matter of associativity is clearly preferential and varies form one language to another, with the majority of languages (reviewed) leaning towards right-associative exponentiation operators due to the usefulness of power-tower. Now, with all this said, that doesn't change the fact that forcing operator precedence is always possible in every language and no good developer would rather be sorry than safe. So why associativity should be a strong basis for accepting or rejecting this RFC is beyond me. Personally, I would rather have the operator in the language, regardless of the associativity, than not have it at all. --047d7bb70ca2ef1c2104eddb2f40--