Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73382 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8517 invoked from network); 24 Mar 2014 16:07:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Mar 2014 16:07:13 -0000 Authentication-Results: pb1.pair.com header.from=ivan.enderlin@hoa-project.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ivan.enderlin@hoa-project.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error) X-PHP-List-Original-Sender: ivan.enderlin@hoa-project.net X-Host-Fingerprint: 95.130.10.56 host1.ip6-networks.net Received: from [95.130.10.56] ([95.130.10.56:33647] helo=host1.ip6-networks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FD/01-02253-F2850335 for ; Mon, 24 Mar 2014 11:07:12 -0500 Received: from Hwhost2.local (184-175.106-92.cust.bluewin.ch [92.106.175.184]) by host1.ip6-networks.net (Postfix) with ESMTPSA id 9ECCF60A87 for ; Mon, 24 Mar 2014 17:07:08 +0100 (CET) Message-ID: <5330582B.1020604@hoa-project.net> Date: Mon, 24 Mar 2014 17:07:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0a2 MIME-Version: 1.0 To: internals@lists.php.net References: <532FF7B9.5040700@hoa-project.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] PHP Specification From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa") Hello Andrea, My answer in the mail. On 24/03/2014 16:52, Andrea Faulds wrote: > On 24 Mar 2014, at 09:15, Ivan Enderlin @ Hoa wrote: > >> All these projects are great for PHP! Yes they are! But, most of these= implementations, interpreters, extensions wrappers etc., are incomplete = or propose extra features that is not in the historical interpreter. The = need of a PHP specification/standard is more and more important: language= syntax, semantics, features, extensions API, etc., must be specified in = order to see more collaborations and quality tools. >> >> We can imagine seeing new contributors on the specification, and whate= ver the implementation, it will benefit to the users and developers. Yes = it will take a lot of time. Yes it will be difficult. Yes it will reveal = some leaks in the historical interpreter. Yes the language will be more i= mportant than the interpreter. But it will give us a lead, a path to foll= ow, a goal, and moreover, it will ensure the same experience to all PHP u= sers no matter the interpreters they used. >> >> If a new interpreter provides a nice feature, then, a discussion can s= tart to update the standard, but if there is no one, which interpreter wi= ll be chosen by the user? If there is a standard, we can compare interpre= ters regarding this standard and not idiotic benchmarks that show anythin= g. >> >> Finally, I think that internal@ is responsible to start such a standar= dization process because this group has made the historical interpreter. = In addition, I think that internal@ is also responsible to promote this s= tandard and invite other actors to collaborate. These last years, PHP has= shown a new face, a face of unity and pragmatism (new release process, R= FC debates etc.). Such a standardization process will be strong and can r= eally put PHP forward. > > I agree, I think PHP needs a specification. For one thing, a reference = implementation is no real specification. It can=92t be easily consulted, = and it also means that any reference implementation bug might be consider= ed a language feature, which other implementations must have. Having a pr= oper specification would mean documentation for users would be easier, to= o. I suppose the specification could become the documentation. I am not sure with the last point. A specification is **not** a=20 documentation. It explains the syntax and the semantics of the language, = whereas the documentation (as currently written) explains the usage, API = and gives examples. But, a specification could perfectly complete a=20 documentation. > However, care would need to be taken when drafting it to make sure that= we are careful to reflect PHP as it actually is (i.e. how the reference = implementation behaves), and not necessarily PHP as it ought to be. If PH= P in practise does not match the specification, it may be useless. Yep, sure! For the first version of the specification, it must match the = prime PHP implementation, aka php-src (I avoid to say =93historical=20 implementation=94 ;-)). And then, the RFC will apply on the specification= =20 and/or the implementation. > PHP=92s current reference implementation and its behaviour are wildly i= nconsistent and, frankly, a bit of a mess. If we were to specify PHP, we = should do so after a major cleanup, say in PHP 6. At the moment, just spe= cifying the ++ operator would require a page. We can target to write the PHP specification along with PHP6=20 implementation. The specification will reflect the PHP6 implementation.=20 And the specification will highlight what is messy in the=20 implementation, and what is not. Consequently, it will provide new clear = goals for future PHP implementations. --=20 Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/