Re: PHP Specification

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 <ivan.enderlin@hoa-project.net> 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 whatever 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 important than the interpreter. But it will give us a lead, a path to follow, a goal, and moreover, it will ensure the same experience to all PHP users no matter the interpreters they used. If a new interpreter provides a nice feature, then, a discussion can start to update the standard, but if there is no one, which interpreter will be chosen by the user? If there is a standard, we can compare interpreters regarding this standard and not idiotic benchmarks that show anything. Finally, I think that internal@ is responsible to start such a standardization process because this group has made the historical interpreter. In addition, I think that internal@ is also responsible to promote this standard and invite other actors to collaborate. These last years, PHP has shown a new face, a face of unity and pragmatism (new release process, RFC debates etc.). Such a standardization process will be strong and can really put PHP forward.

I agree, I think PHP needs a specification. For one thing, a reference implementation is no real specification. It can’t be easily consulted, and it also means that any reference implementation bug might be considered a language feature, which other implementations must have. Having a proper specification would mean documentation for users would be easier, too. I suppose the specification could become the documentation. I am not sure with the last point. A specification is **not** a 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 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 PHP 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 “historical implementation” ;-)). And then, the RFC will apply on the specification and/or the implementation.

PHP’s current reference implementation and its behaviour are wildly inconsistent 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 specifying the ++ operator would require a page. We can target to write the PHP specification along with PHP6 implementation. The specification will reflect the PHP6 implementation. And the specification will highlight what is messy in the implementation, and what is not. Consequently, it will provide new clear goals for future PHP implementations.

-- 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/