Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73414
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.10.56 cause and error)
Message-ID: <53313EE6.4000806@hoa-project.net>
Date: Tue, 25 Mar 2014 09:31:34 +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> <DD864C7C-6497-411A-9815-36D7662B2846@ajf.me> <5330582B.1020604@hoa-project.net> <5330661B.80202@garfieldtech.com> <5330E334.7060109@gmail.com>
In-Reply-To: <5330E334.7060109@gmail.com>
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 Gary and Larry :-),


On 25/03/2014 03:00, Gary Mort wrote:
> On 03/24/2014 01:06 PM, Larry Garfield wrote:
>> This has been discussed before in the PHP-next-major context.  A
>> language or protocol can either be defined canonically by a
>> specification or a reference implementation; it is impossible for it t=
o
>> be defined by both.  (Even if they match perfectly, which is almost
>> unheard of, one of them is still the Authoritative Source of=20
>> Answers(tm).)
>>
>> PHP is currently implementation-defined; that is, the answer to "what =
is
>> PHP supposed to do?" is always "whatever php-src does right now".  Eve=
n
>> if everyone thinks that's a bug, it means it's technically an API chan=
ge
>> to impact php-src's behavior.  It also makes alternate implementations=

>> much harder.
>>
>> A spec-defined language/protocol is easier to evolve, and easier to
>> build alternate implementations for.  In general I believe that to be =
a
>> far superior approach.  It is, however, totally not simple to shift fr=
om
>> an implementation to specification approach; I can't imagine it could =
be
>> done without nominal API changes in edge cases, no matter how hard we =

>> try.
>>
>> Which is exactly why PHP-next-major (6, 7, whatever it's called) would=

>> be the ideal time, really the only time, to make that transition.
>
> Trying to write a "PHP Specification" that covers everything seems=20
> like a mountain of a task.
Oh yeah=85


> Why not let it BE both?  IE the PHP Spec can be the authoritive word=20
> on how it should behave for the items covered by the spec. Anything not=

> covered by the spec is defined in the Reference implementation.
>
> When undocumented features/bugs are discovered, open a RFC to define=20
> the specification.  A specification RFC does not need to match how the =

> reference behaves today, it can define it as how it should behave.  If =

> the RFC spec passes by vote, then if someone wants to open an RFC to=20
> modify the reference to match the spec, they can, and the voting=20
> process can determine what version that change will occur in.
>
> Even though the RFC process has matured and it is believed that=20
> current RFC's are of better clarity and that php-src matches those=20
> RFC's, I'd bet money that it is possible to find at least one edge=20
> case where the RFC specifies something different from what php-src is=20
> actually doing. As such, even recent RFC's cannot be considered=20
> specifications - if someone wants to make them such they have to=20
> re-submit them.
I am not sure to understand your proposal well, but instead of producing =

a full complete specification at first, we should focus on important=20
features than other implementations do not support. Typically, the fact=20
the `php` binary reads from its stdin is missing most of the time.

I imagine to start the specification at different levels:

   * the syntax, which is not easy since PHP grammars is ambigious but=20
it's feasible in a reasonable time,
   * the semantics, very very important, it will describe how data are=20
represented, objects etc., how they behaves, it will clarify a lot of thi=
ngs
   * the tool, i.e. the PHP architecture through SAPI, one of the most=20
clever feature of PHP,
   * the extension, how are they split in different directories, how to=20
load them etc. (still from the user point of view)
   * then the standard library, which includes ext/core, ext/standard,=20
ext/stream etc.

The goal is not, at first, to specify the behavior of all functions.=20
This would be totally crazy. PHP has a big tests suite to check that.=20
Before, the most important thing (for me) is to specify the langage=20
(syntax, semantics and tool). This is a good start and a nice task since =

types, auto-boxing, generators etc., will be described in those parts.


> This also means that those who are writing alternative PHP=20
> implementations can easily submit their understandings as PHP=20
> specification RFC's and they can do so if it is important to them.
Exactly. RFC will still be the point where to propose new features.

--=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/