Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70322
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHMUw2EmaofC=An8o=QrjnHAmdmtjprnCi69sRjMYcPDy37TDg@mail.gmail.com>
References: <CAHMUw2EmaofC=An8o=QrjnHAmdmtjprnCi69sRjMYcPDy37TDg@mail.gmail.com>
Date: Sat, 23 Nov 2013 17:02:54 +0800
Message-ID: <CAHMUw2F_CBCsQg4RtpbyJ14OxsjeC2Zw+=ooCvBS+pgB-2Gdcg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86e3d87941ab04ebd46568
Subject: Re: Power function as operator
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--047d7b86e3d87941ab04ebd46568
Content-Type: text/plain; charset=ISO-8859-1

Hi again,

On Sat, Nov 23, 2013 at 12:58 AM, Tjerk Meesters
<tjerk.meesters@gmail.com>wrote:

> Hi,
>
> To challenge myself I had tasked myself to introduce a new operator and
> opcode to the language; now that I'm done with it, I wanted to measure the
> response on the list to actually get it merged before writing an RFC.
>
> My work can be found here:
> https://github.com/datibbaw/php-src/compare/pow-operator
>
> It introduces the pow() function as an operator ** (double asterisk), as
> can be found in languages such as Python (with perhaps the notable
> difference that it's right associative there).
>
> The logic gets exposed via the ZEND_POW opcode and all the logic that went
> into pow() itself is copied into it. The exceptions are that an expression
> such as [] ** 2 (squared empty array) will cause a fatal error because the
> operands are incompatible, whereas pow([], 2) would give 0.
>
> Why this operator? Basically because:
> 1) it's shorter (the keyboard rejoices).
> 2) it's faster (no ZEND_CALL).
> 3) it's found in other languages too.
>
> I've only implemented one of the test suites; there are quite a few for
> just one function, but when needed I can add those others as well.
>
> Btw, changes to vld aren't pushed yet.
>
> Let me know!
>
> --
> --
> Tjerk
>

So far, there have been no violent objections against the proposal, so I
shall go ahead and effect the following:
1) Investigate the GMP overloading option.
2) Write an RFC

As for the associativity argument (assuming the precedence is now correct),
if not resolved before the voting begins, I would suggest to move that into
the vote itself, i.e.:
a) don't implement;
b) yes, with left associativity;
c) yes, with right associativity.


-- 
--
Tjerk

--047d7b86e3d87941ab04ebd46568--