FAQ

[PHP-INTERNALS] PHP Language Specification

Sara Golemon
Jul 22, 2014 at 7:50 pm
Just announced something at OSCON that's probably going to get a lot
of folks talking and making assumptions, so before things get out of
hand, I want to provide some context.

We (As in PHP) have been talking about making a spec for the PHP
language for a LONG time. With PHPNG around the corner, the need for
a formal spec is even more important so that we can reliably ensure
that PHP.Next matches PHP 5.6's behavior as much as possible.
Meanwhile, other implementations of PHP (like HHVM) should be as spec
compliant as possible so that we don't see the language bifurcate.

To that end, we (as in Facebook), have been putting together a formal
language spec for PHP (using PHP 5.6 as the source of truth) along
with an additional conformance test suite (which compliments
Zend/tests). We've talked to some engine folks along the way to get
feedback and make version 1 as good as it can be, and we're really
close to releasing it (aiming for next week). Note that this document
only covers the language syntax and not the standard runtime library.

This document is meant for PHP, and PHP should be the steward of it
going forward, so we (as in PHP) should start looking at good ways to
keep it up to date and revise it over time. As a sneak-peak, uploaded
a very small section so that you get an idea for what the
document looks like overall.

http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf

Tons of love,
-Sara

P.S. - Apologies if you got this twice. But the version I sent with an
attachment looks like it got stripped by the list server.
reply

Search Discussions

71 responses

  • Rican7 at Jul 22, 2014 at 8:33 pm
    Sara, I can't even begin to thank you and your team enough for this. This
    is incredibly huge.

    You're right, a spec has become even more important with new engines and
    implementations like PHPNG and HHVM in the works. I wondered if this were
    to ever happen. It never seemed like anyone in the PHP community wanted to
    spearhead this kind of work (for good reason, its difficult and a huge task
    to undertake).

    Thank you so much! Again, this is huge!

    - Trevor

    On Tue, Jul 22, 2014 at 3:50 PM, Sara Golemon wrote:

    Just announced something at OSCON that's probably going to get a lot
    of folks talking and making assumptions, so before things get out of
    hand, I want to provide some context.

    We (As in PHP) have been talking about making a spec for the PHP
    language for a LONG time. With PHPNG around the corner, the need for
    a formal spec is even more important so that we can reliably ensure
    that PHP.Next matches PHP 5.6's behavior as much as possible.
    Meanwhile, other implementations of PHP (like HHVM) should be as spec
    compliant as possible so that we don't see the language bifurcate.

    To that end, we (as in Facebook), have been putting together a formal
    language spec for PHP (using PHP 5.6 as the source of truth) along
    with an additional conformance test suite (which compliments
    Zend/tests). We've talked to some engine folks along the way to get
    feedback and make version 1 as good as it can be, and we're really
    close to releasing it (aiming for next week). Note that this document
    only covers the language syntax and not the standard runtime library.

    This document is meant for PHP, and PHP should be the steward of it
    going forward, so we (as in PHP) should start looking at good ways to
    keep it up to date and revise it over time. As a sneak-peak, uploaded
    a very small section so that you get an idea for what the
    document looks like overall.

    http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf

    Tons of love,
    -Sara

    P.S. - Apologies if you got this twice. But the version I sent with an
    attachment looks like it got stripped by the list server.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrea Faulds at Jul 22, 2014 at 10:15 pm

    On 22 Jul 2014, at 20:50, Sara Golemon wrote:

    To that end, we (as in Facebook), have been putting together a formal
    language spec for PHP (using PHP 5.6 as the source of truth) along
    with an additional conformance test suite (which compliments
    Zend/tests). We've talked to some engine folks along the way to get
    feedback and make version 1 as good as it can be, and we're really
    close to releasing it (aiming for next week). Note that this document
    only covers the language syntax and not the standard runtime library.

    This document is meant for PHP, and PHP should be the steward of it
    going forward, so we (as in PHP) should start looking at good ways to
    keep it up to date and revise it over time. As a sneak-peak, uploaded
    a very small section so that you get an idea for what the
    document looks like overall.

    http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf
    This is awesome! Finally, PHP gets a specification.

    Good luck documenting PHP’s inconsistent semantics, though. It’ll either be endlessly detailed, or not matching PHP 5.6. To be honest, I think we should probably clean up PHP’s semantics so they can be more clearly specified.
    --
    Andrea Faulds
    http://ajf.me/
  • Sara Golemon at Jul 22, 2014 at 10:32 pm

    On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds wrote:
    Good luck documenting PHP’s inconsistent semantics, though.
    It’ll either be endlessly detailed, or not matching PHP 5.6.
    To be honest, I think we should probably clean up PHP’s
    semantics so they can be more clearly specified.
    200 pages in the draft I have atm...

    As you suppose, some of that bulk is down to the kinds of things that
    the Unified Variable Syntax RFC is trying to resolve. On the plus
    side, the guy who's been writing the spec is insanely detail oriented
    (and has experience writing language specs), so all those inconsistent
    semantics are represented. :)
  • Andrea Faulds at Jul 22, 2014 at 10:35 pm

    On 22 Jul 2014, at 23:32, Sara Golemon wrote:

    As you suppose, some of that bulk is down to the kinds of things that
    the Unified Variable Syntax RFC is trying to resolve. On the plus
    side, the guy who's been writing the spec is insanely detail oriented
    (and has experience writing language specs), so all those inconsistent
    semantics are represented. :)
    Does it handle the fact that ‘0xa’ is variously zero and ten in string to integer conversions? :)

    --
    Andrea Faulds
    http://ajf.me/
  • Sara Golemon at Jul 22, 2014 at 10:36 pm

    On Tue, Jul 22, 2014 at 3:34 PM, Andrea Faulds wrote:
    On 22 Jul 2014, at 23:32, Sara Golemon wrote:
    As you suppose, some of that bulk is down to the kinds of things that
    the Unified Variable Syntax RFC is trying to resolve. On the plus
    side, the guy who's been writing the spec is insanely detail oriented
    (and has experience writing language specs), so all those inconsistent
    semantics are represented. :)
    Does it handle the fact that ‘0xa’ is variously zero and ten in string to integer conversions? :)
    Yep. Isn't PHP a gorgeous language? :p
  • Larry Garfield at Jul 22, 2014 at 10:37 pm

    On 7/22/14, 5:32 PM, Sara Golemon wrote:
    On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds wrote:
    Good luck documenting PHP’s inconsistent semantics, though.
    It’ll either be endlessly detailed, or not matching PHP 5.6.
    To be honest, I think we should probably clean up PHP’s
    semantics so they can be more clearly specified.
    200 pages in the draft I have atm...

    As you suppose, some of that bulk is down to the kinds of things that
    the Unified Variable Syntax RFC is trying to resolve. On the plus
    side, the guy who's been writing the spec is insanely detail oriented
    (and has experience writing language specs), so all those inconsistent
    semantics are represented. :)
    PHP.next seems like a good time to possibly fix a few of those
    inconsistencies for the sake of a more sane language definition if the
    BC break is small enough (as the UVS RFC is doing).

    The big question here, though, is whether, going forward, we'll be able
    to mentally switch to a "spec first" mentality. If not, the spec will
    get out of date and become less than useful. I hope we're able to make
    that transition.

    Also: zOMG THANK YOU FOR DOING THIS!!!

    --Larry Garfield
  • Andrea Faulds at Jul 22, 2014 at 10:41 pm

    On 22 Jul 2014, at 23:37, Larry Garfield wrote:

    The big question here, though, is whether, going forward, we'll be able to mentally switch to a "spec first" mentality. If not, the spec will get out of date and become less than useful. I hope we're able to make that transition.
    I think that’s unrealistic. It will always be Zend code first, spec second. HHVM can play catch-up ;)
    --
    Andrea Faulds
    http://ajf.me/
  • Ben Ramsey at Jul 22, 2014 at 10:48 pm

    On Jul 22, 2014, at 5:41 PM, Andrea Faulds wrote:
    On 22 Jul 2014, at 23:37, Larry Garfield wrote:

    The big question here, though, is whether, going forward, we'll be able to mentally switch to a "spec first" mentality. If not, the spec will get out of date and become less than useful. I hope we're able to make that transition.
    I think that’s unrealistic. It will always be Zend code first, spec second. HHVM can play catch-up ;)
    IMO, I think this renders the spec useless. If we’re not going to have a “spec first” mentality, then what is the point of having a spec? It benefits us all to think “spec first.”

    -Ben
  • Sara Golemon at Jul 22, 2014 at 10:48 pm

    On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds wrote:
    On 22 Jul 2014, at 23:37, Larry Garfield wrote:
    The big question here, though, is whether, going forward, we'll be
    able to mentally switch to a "spec first" mentality. If not, the spec will
    get out of date and become less than useful. I hope we're able to
    make that transition.
    I think that’s unrealistic. It will always be Zend code first, spec second.
    HHVM can play catch-up ;)
    I dunno, with syntax changes being 2/3rd majority and our formal RFC
    process in place, I think we (PHP) can reasonably learn to make
    updating the spec a formal part of our process.

    -Sara
  • Andrea Faulds at Jul 22, 2014 at 10:56 pm

    On 22 Jul 2014, at 23:48, Sara Golemon wrote:
    On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds wrote:
    On 22 Jul 2014, at 23:37, Larry Garfield wrote:
    The big question here, though, is whether, going forward, we'll be
    able to mentally switch to a "spec first" mentality. If not, the spec will
    get out of date and become less than useful. I hope we're able to
    make that transition.
    I think that’s unrealistic. It will always be Zend code first, spec second.
    HHVM can play catch-up ;)
    I dunno, with syntax changes being 2/3rd majority and our formal RFC
    process in place, I think we (PHP) can reasonably learn to make
    updating the spec a formal part of our process.
    Ah, I think you misunderstand. What I mean is that we should only propose RFCs which change the spec when there is already a working implementation first. Otherwise, we might add things to the spec which won’t or can’t get implemented. It would also be best to propose changes which have been implemented in Zend, to ensure there is one fully compliant implementation.

    --
    Andrea Faulds
    http://ajf.me/
  • Sara Golemon at Jul 22, 2014 at 11:01 pm

    On Tue, Jul 22, 2014 at 3:56 PM, Andrea Faulds wrote:
    Ah, I think you misunderstand. What I mean is that we
    should only propose RFCs which change the spec
    when there is already a working implementation first.
    Otherwise, we might add things to the spec which won’t
    or can’t get implemented. It would also be best to propose
    changes which have been implemented in Zend, to ensure
    there is one fully compliant implementation.
    Our RFCs tend to have implementations attached to them (in someone's
    personal fork). IMO we should make creating the spec PR part of the
    RFC acceptance process, and that they should be landed together. I
    agree it doesn't make much sense to define unimplemented behavior as
    the standard.
  • Andrea Faulds at Jul 22, 2014 at 11:04 pm

    On 23 Jul 2014, at 00:01, Sara Golemon wrote:
    Our RFCs tend to have implementations attached to them (in someone's
    personal fork). IMO we should make creating the spec PR part of the
    RFC acceptance process, and that they should be landed together. I
    agree it doesn't make much sense to define unimplemented behavior as
    the standard.
    I would very much agree with that. An advantage of adding to the spec with the RFC is people can check how well the patch lines up with the spec, too.

    --
    Andrea Faulds
    http://ajf.me/
  • Sebastian Bergmann at Jul 23, 2014 at 10:44 am

    On 07/23/2014 12:48 AM, Sara Golemon wrote:
    I dunno, with syntax changes being 2/3rd majority and our formal RFC
    process in place, I think we (PHP) can reasonably learn to make
    updating the spec a formal part of our process.
       Requiring an RFC that changes syntax (or core semantics) to provide a
       patch for the specification in addition to the tests should suffice, no?
  • Sara Golemon at Jul 22, 2014 at 10:22 pm

    On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon wrote:
    This document is meant for PHP, and PHP should be the steward of it
    going forward, so we (as in PHP) should start looking at good ways to
    keep it up to date and revise it over time.
    Some folks in IRC asked for clarification of this point.

    FB isn't looking to just throw this over wall saying "HERE'S THE FINAL
    DOCUMENT, HAVE A NICE DAY, GOOD BYE!". What we're planning to release
    next week is more like a pre-1.0 draft which will probably need a lot
    of work before anyone is willing to call it final, and of course the
    document will need to be updated over time to reflect changes in the
    language's syntax (e.g. return typehint rfc).

    We're happy to setup the framework for curating that document
    (probably as a github project), but don't want to be all controlling
    with it, so if the PHP Group as an organization wants to own it and
    manage updates to it over time, all the better. If that means FB sets
    it up then hands it over, that's an option too. This is the
    discussion I'd like to start now, so that we can work out a strategy
    for what that looks like.

    If folks have comments on the one chapter I uploaded, I'd say start
    with emails to the list or me directly and I'll pass them on. That
    should be considered a short-term solution though. Ideally we'll have
    something in a collaborative format next week that folks with existing
    karma can contribute to more directly.

    -Sara
  • Andrea Faulds at Jul 22, 2014 at 10:25 pm

    On 22 Jul 2014, at 23:22, Sara Golemon wrote:

    We're happy to setup the framework for curating that document
    (probably as a github project), but don't want to be all controlling
    with it, so if the PHP Group as an organization wants to own it and
    manage updates to it over time, all the better. If that means FB sets
    it up then hands it over, that's an option too. This is the
    discussion I'd like to start now, so that we can work out a strategy
    for what that looks like.
    Myself I think it’d be best if the PHP Group runs it. The same organisation controlling the specification and the reference implementation of sorts (Zend PHP) is probably more practical than some external organisation. It’s also worked pretty well so far. :)
    --
    Andrea Faulds
    http://ajf.me/
  • Sebastian Bergmann at Jul 23, 2014 at 10:54 am

    On 07/23/2014 12:25 AM, Andrea Faulds wrote:
    Myself I think it’d be best if the PHP Group runs it.
       And who exactly is the PHP Group? Most of the people listed in the
       credits as "The PHP Group" have not contributed in years.

       I agree, though, that the PHP project should own the language
       specification effort.
  • Pascal Chevrel at Jul 23, 2014 at 11:58 am

    Le 23/07/2014 12:54, Sebastian Bergmann a écrit :
    On 07/23/2014 12:25 AM, Andrea Faulds wrote:
    Myself I think it’d be best if the PHP Group runs it.
    And who exactly is the PHP Group? Most of the people listed in the
    credits as "The PHP Group" have not contributed in years.

    I agree, though, that the PHP project should own the language
    specification effort.
    Hi,

    What is the process to get this list updated and actually useful?

    I looked at the page (http://php.net/credits.php) and was surprised not
    to see listed the people that seem to me to be the people actually
    maintaining and making the language progress in the last years. Some of
    the biggest committers in the last 4 years are not credited at all
    (Nikita Popov, Joe Watkins, Anatol Belski...), which is abnormal IMO.

    It's not clear to me either who the PHP Group is compared to say the PHP
    authors section. What is their role? How do they help the project as a
    group? Do they meet or did they meet in the past? If almost all of them
    haven't been involved in the project for years, why are they listed?
    Interestingly, a colleague of mine is listed as one of the members of
    the PHP Group and I didn't know. I am pretty sure he hasn't been
    involved in PHP for like, 10 years :D.

    Could somebody that was in the project 15 years ago explain us what was
    the idea, duties and responsabilities that this group was supposed to have?

    Regards,

    Pascal
  • Zeev Suraski at Jul 23, 2014 at 12:18 pm

    -----Original Message-----
    From: Pascal Chevrel
    Sent: Wednesday, July 23, 2014 2:58 PM
    To: internals@lists.php.net
    Subject: Re: [PHP-DEV] PHP Group, what is it? (was Re:PHP Language
    Specification)

    Could somebody that was in the project 15 years ago explain us what was
    the
    idea, duties and responsabilities that this group was supposed to have?
    That group is simply the key people who created the project some 15+, or
    rather almost 20 years ago. It's mostly defunct as a governing body at this
    point, with practically all decisions happening here on internals@; It's
    still there as, and it's theoretically still the group that holds the
    copyright and the right to change fundamental things like the license,
    although in practice, this too will happen through RFCs if it ever does,
    most probably. I'd say its main goal today is to be a last line of defense
    in case of a hostile attempt of Perl activists to take over internals@ :)
    Ideally we don't need to defer anything to this group, and handle mostly
    everything in RFCs.

    BTW, the Authors list could definitely use some updates, and IIRC, Ferenc
    actually worked on that recently for 5.6.0.

    Zeev
  • Ivan Enderlin @ Hoa at Jul 23, 2014 at 1:04 pm
    Hello Sara,

    First, thank you for the hard work. I have started to work on it few
    days ago as suggested in [1]. You have been faster than me ;-). Good job!

    On 23/07/2014 00:22, Sara Golemon wrote:
    On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon wrote:
    This document is meant for PHP, and PHP should be the steward of it
    going forward, so we (as in PHP) should start looking at good ways to
    keep it up to date and revise it over time.
    Some folks in IRC asked for clarification of this point.

    FB isn't looking to just throw this over wall saying "HERE'S THE FINAL
    DOCUMENT, HAVE A NICE DAY, GOOD BYE!". What we're planning to release
    next week is more like a pre-1.0 draft which will probably need a lot
    of work before anyone is willing to call it final, and of course the
    document will need to be updated over time to reflect changes in the
    language's syntax (e.g. return typehint rfc).
    This is a good news. The approach of Facebook is sane as I can see and
    this is comforting.

    You said your target was PHP5.6. With Pierre Joye, when we talked about
    the PHP Specification, we have mentionned to target PHP6 since (i) it
    will solve several PHP inconsistencies and (ii) PHP6 requires 2 years to
    be released, just like the PHP Specification (approximately).

    We're happy to setup the framework for curating that document
    (probably as a github project), but don't want to be all controlling
    with it, so if the PHP Group as an organization wants to own it and
    manage updates to it over time, all the better. If that means FB sets
    it up then hands it over, that's an option too. This is the
    discussion I'd like to start now, so that we can work out a strategy
    for what that looks like.
    My idea was to constitute a **PHP Consortium** (yes, the name is classy
    but it reflects the reality), responsible to maintain and edit the PHP
    Specification. With what members? Members from the PHP Group
    (maintainers of php-src), from Facebook (maintainers of HHVM), from
    HippyVM, from JPHP etc. and from others important projects (e.g.
    Symfony, Zend etc.), just like the PHP Group does with the RFC votes.
    What will be the size of the PHP Consortium? I don't know. Having more
    than 100 persons, even qualified, would not be a good idea. A process
    must be sketch to propose, discuss and accept RFC, features etc. The
    group responsible to validate RFC will be the PHP Consortium. This is
    not a technical position, but a “language-semantics” position, in order
    to avoid conflicts between different vendors (VM mainteners).

    I am wondering whether it is possible to adopt an approach similar to
    the W3C: several people working “punctually” on a feature. On one side
    we have authors, and on the other side, we have “commenters”. The
    workflow is pretty efficient also:
        * writing a proposal,
        * discussing,
        * trying different implementations,
        * collecting feedbacks from the users, and finally,
        * validating it.
    We should not met the issues encountered by the W3C and HTML vendors
    because the rate of releases is not the same (fortunately!). Another
    source of inspiration can be the process of the ECMAScript language.


    If folks have comments on the one chapter I uploaded, I'd say start
    with emails to the list or me directly and I'll pass them on.
    Please, send me the first chapter :-). I have written specifications for
    two languages, my skills can be interesting (this is why I have started
    [1]).

    That
    should be considered a short-term solution though. Ideally we'll have
    something in a collaborative format next week that folks with existing
    karma can contribute to more directly.
    Several people have proposed Github, markdown etc. From my point of view
    and experience, this will be insane to manage. If everyone can make a
    proposal, this will lead to a lot of noise. PHP allows *some* users to
    write RFC. If someone would like to see a new feature, it has to
    approach someone with a higher karma/rights or to join the ML
    (mailing-list) of the PHP Consortium. Also, about the format, we should
    use an advanced one (so it excludes markdown, sorry guys :-)).


    Finally, a lot of questions remain open, like:
        * What version numbers for the specification? Will they follow the
    versions of php-src (the “historical implementation”, haha</trolling>)
        * Will the PHP Consortium be splitted into several groups according
    to the specification's chapters (for example: the stream part, the
    runtime part, the security part etc.)
        * Will a test suite to check the conformance of an implementation to
    the PHP Specification be provided?
        * What are the goals of the PHP Specification? I mean: What are the
    subjects? Will it include the extensions, or the definition of extensions?

    Maybe I have missed this information but why Facebook is keeping the
    sources of the PHP Specification private for now? I'm not judging, just
    asking :-).

    Again, really great work. Thank you!
    Best regards.



    [1] http://marc.info/?l=php-internals&m=139565259319206

    --
    Ivan Enderlin
    Developer of Hoa
    http://hoa-project.net/

    PhD 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/
  • Rowan Collins at Jul 23, 2014 at 7:02 pm

    Ivan Enderlin @ Hoa wrote (on 23/07/2014):
    My idea was to constitute a **PHP Consortium** (yes, the name is
    classy but it reflects the reality), responsible to maintain and edit
    the PHP Specification. With what members? Members from the PHP Group
    (maintainers of php-src), from Facebook (maintainers of HHVM), from
    HippyVM, from JPHP etc. and from others important projects (e.g.
    Symfony, Zend etc.), just like the PHP Group does with the RFC votes.
    This sounds like a nice idea, but there would then be an awkward
    relationship between this process and the existing RFC process.

    Currently, an RFC can be proposed and discussed within internals@ which
    makes changes to the language as implemented by the de facto reference
    implementation.

    If that process is not allowed to change the specification directly,
    then the Zend/php.net implementation would cease to conform to the
    specification, until such time as The Consortium also accepted the
    change, and updated the specification to match. If the change was
    rejected, there would be a power struggle: either the RFC process would
    have lost power over the language, or the specification would disagree
    with its oldest and most popular implementation.

    On the flip side, there is definitely value in representatives from
    other implementations having a voice in changes that affect them, but
    that could just mean ensuring that members of those projects are
    involved within the current framework.

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Andrea Faulds at Jul 23, 2014 at 7:05 pm

    On 23 Jul 2014, at 19:59, Rowan Collins wrote:

    On the flip side, there is definitely value in representatives from other implementations having a voice in changes that affect them, but that could just mean ensuring that members of those projects are involved within the current framework.
    I think we should take this approach. Give accounts with voting rights to people that matter from outside internals.

    --
    Andrea Faulds
    http://ajf.me/
  • Ben Ramsey at Jul 23, 2014 at 8:59 pm

    On Jul 23, 2014, at 1:59 PM, Rowan Collins wrote:
    On the flip side, there is definitely value in representatives from other implementations having a voice in changes that affect them, but that could just mean ensuring that members of those projects are involved within the current framework.
    In this way, the de facto concept of “PHP” becomes the language specification, rather than any given implementation. All implementors should have input on the direction of the language specification. Again, returning to that idea of thinking “spec first.”

    We might refer to the PHP Group implementation (sometimes called the “Zend PHP” implementation by other implementations) as the canonical implementation of the specification, but that’s because the PHP Group, which owns the language specification, also owns the canonical implementation.

    This got me thinking about the whole version number debate. With a language specification, to what does the version number refer? The state of the language specification, or the state of a given implementation of the specification? Right now, the number refers to the state of the PHP Group implementation, and implementations like HippyVM and HHVM say that they are compatible with Zend PHP 5.x. Will we version the language specification separately, and individual releases of various implementations (including the PHP Group implementation) will state that they are compatible with version X of the specification?

    -Ben
  • Andrea Faulds at Jul 23, 2014 at 9:28 pm

    On 23 Jul 2014, at 21:59, Ben Ramsey wrote:

    This got me thinking about the whole version number debate. With a language specification, to what does the version number refer? The state of the language specification, or the state of a given implementation of the specification? Right now, the number refers to the state of the PHP Group implementation, and implementations like HippyVM and HHVM say that they are compatible with Zend PHP 5.x. Will we version the language specification separately, and individual releases of various implementations (including the PHP Group implementation) will state that they are compatible with version X of the specification?
    As I see it, Zend PHP will continue to be the ‘reference implementation’ of sorts, though we might see a shift to the point where the specification defines the semantics, not Zend PHP.

    For majors and minors things are quite clear-cut. Zend PHP 5.6 implements PHP 5.6 as specified, and I imagine that HHVM foo.bar is going to say it’s “5.6-compliant” or something of the sort. The problem is micro versions. 5.6.1 is probably going to be a bug fix release, but why would there be a “5.6.1” specification when the problem was with one specific implementation?

    I’m not really a fan of having different versions of the PHP spec and Zend PHP, they should match up IMO. However, we run into the previously described problem.

    Perhaps we should switch to having four numbers: major, minor, micro and nano. Major, minor and micro would be reserved to the specification, and nano would be reserved for Zend PHP. So you’d have Zend PHP 5.6.0.1 which might fix a bug but implements the 5.6(.0) spec, and you might have the PHP 5.6.1 spec version which fixes an error in the specification or adds a minor version.

    Another option is to use a dash to separate things. specification-implementation, so 5.6.0-1 for the second Zend PHP implementation of the 5.6.0 spec, and 5.6.1-0 for the first Zend PHP implementation of the 5.6.1 spec.

    Actually, it occurs to me now that having micro versions of the spec is probably not a good idea and we should just keep to the de facto current scheme of only adding features in minors and only fixing bugs in micros. That way the spec doesn’t need a third number, and we can just reserve that third digit to the release of Zend PHP, which lines up nicely with what we’re doing just now.

    What are others’ thoughts on this? Should we split into PHP spec versions and Zend PHP versions?

    --
    Andrea Faulds
    http://ajf.me/
  • Rowan Collins at Jul 23, 2014 at 10:08 pm

    On 23/07/2014 22:27, Andrea Faulds wrote:
    For majors and minors things are quite clear-cut. Zend PHP 5.6 implements PHP 5.6 as specified, and I imagine that HHVM foo.bar is going to say it’s “5.6-compliant” or something of the sort. The problem is micro versions. 5.6.1 is probably going to be a bug fix release, but why would there be a “5.6.1” specification when the problem was with one specific implementation?
    [For clarity, the below refers to 3-part version numbers as
    Major.Minor.Patch, per http://semver.org]

    We can probably assume (or even mandate!) that any change that required
    a change to the specification would need to be in a new minor version of
    Zend PHP, whereas changes in patch releases would be either
    specification-neutral, or fixing bugs in the implementation to better
    match the specification.

    That means that the specification itself would only need a major.minor
    version, e.g. "PHP Specification 5.6" would correspond to the behaviour
    of all Zend PHP 5.6.x releases.

    There might, however, be bugs in the specification itself, which would
    require additional editorial eleases which were better attempts to
    describe the same functionality. To make clear that these don't
    correspond with the patch releases of the code, a different convention
    could be used, e.g.: "5.6r1" ("PHP Specification 5.6, revision 1"); or
    "5.6a".

    Alternatively, it could start fresh from 1.0, and then approximately
    track releases, in the same way that we have Zend Engine 2, not 5 (I'm
    guessing phpng, if accepted, will be Zend Engine 3?). I think the
    "backwards compatibility" of being able to say "PHP 5.6 compliant" is
    attractive though.

    --
    Rowan Collins
    [IMSoP]
  • Ivan Enderlin @ Hoa at Jul 24, 2014 at 12:30 pm

    On 23/07/2014 22:59, Ben Ramsey wrote:
    This got me thinking about the whole version number debate. With a language specification, to what does the version number refer? The state of the language specification, or the state of a given implementation of the specification? Right now, the number refers to the state of the PHP Group implementation, and implementations like HippyVM and HHVM say that they are compatible with Zend PHP 5.x. Will we version the language specification separately, and individual releases of various implementations (including the PHP Group implementation) will state that they are compatible with version X of the specification?
    This is exactly what I said in “a lot of questions remain open” in my
    previous mail [1]. Taking the example of XML, CSS, HTML, ECMAScript or
    other languages (maybe the JVM, I don't know exactly), there is version
    numbers for the specification, that are different of the version numbers
    of the implementations. Even more, the version of the implementations is
    most of the time unknown (what is the version of SpiderMonkey or V8 for
    ECMAScript x? We don't really know).

    In the case of PHP, this is different because the word “PHP” was
    previously (yes, it's done) representing the language **and** the
    implementation. Consequently, we can't start with PHP1.

    1. A solution would be to start with PHP6 (and 7, I don't know…) for the
    specification, and then, the version of the implementations will have no
    importance (HHVM1.3, ZendEngine3.0, whatever you want).
    2. Another solution is to refer to the PHP version with a “new name”,
    something like “PHPx” or “PHPv”, so we will have "PHPx1”, “PHPx2” etc.
    3. A final solution I see is to refer to PHP with “PHP1” which will be
    equivalent to “PHP6.1”, exactly as Java7 which is in reality Java1.7,
    but when they will introduce Java2.x, they will encounter a problem…

    My favorite solution is the 2nd one.

    Moreover, what about (let's say with PHPx) PHPx1.2.3? Does it make sense
    to have x.y.z for a language specification? We don't see it very often.
    Actually, x.y is enough I would say (XML1.1, Java1.7 etc.), I don't know
    any x.y.z language specification.

    Another problem to solve: what about the `php_version` function, the
    `PHP_VERSION_ID` constant etc. If an implementation (a VM) respects the
    specification, testing the version of the specification does not make
    sense anymore, except in edge-cases, so we will really test the version
    of language. Do we keep these functions and constants? Do we introduce
    new ones? The specification might define the format of some functions
    or constants to get the versions of the implementation, for example:
    `PHP_VM_VERSION_ID` along with `PHP_VM_NAME` (something similar to what
    PHP does with SAPI).

    Thoughts?


    [1] http://marc.info/?l=php-internals&m=140612071919140&w=2

    --
    Ivan Enderlin
    Developer of Hoa
    http://hoa-project.net/

    PhD. 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/
  • Rowan Collins at Jul 24, 2014 at 1:43 pm

    Ivan Enderlin @ Hoa wrote (on 24/07/2014):
    Taking the example of XML, CSS, HTML, ECMAScript or other languages
    (maybe the JVM, I don't know exactly), there is version numbers for
    the specification, that are different of the version numbers of the
    implementations. Even more, the version of the implementations is most
    of the time unknown (what is the version of SpiderMonkey or V8 for
    ECMAScript x? We don't really know).
    I think this only really matters if it's likely that the Zend
    implementation diverges from the specification, such as by a feature
    being implemented in HHVM and agreed to be standard, but no release of
    Zend produced supporting that feature. And that in turn implies a
    separate stewardship and decision-making process for the implementation
    and the specification, which would be a major change in process.

    Incidentally, that's another question: some people like to make clear
    that the Zend Engine isn't actually the language implementation, it just
    *powers* the implementation. In which case, what *should* the
    implementation be called?

    --
    Rowan Collins
    [IMSoP]
  • Andrea Faulds at Jul 24, 2014 at 2:28 pm

    On 24 Jul 2014, at 14:40, Rowan Collins wrote:

    Incidentally, that's another question: some people like to make clear that the Zend Engine isn't actually the language implementation, it just *powers* the implementation. In which case, what *should* the implementation be called?
    That’s actually an important question. I always tend to say “Zend PHP” here, but I’m a little bit uneasy about having Zend in the name. Perhaps “the PHP.net implementation”? “PHP Group implementation”? “PHP reference implementation”?

    We could take a leaf from Python’s book and call it CPHP :)

    --
    Andrea Faulds
    http://ajf.me/
  • Rowan Collins at Jul 24, 2014 at 2:47 pm

    Andrea Faulds wrote (on 24/07/2014):
    On 24 Jul 2014, at 14:40, Rowan Collins wrote:

    Incidentally, that's another question: some people like to make clear that the Zend Engine isn't actually the language implementation, it just *powers* the implementation. In which case, what *should* the implementation be called?
    That’s actually an important question. I always tend to say “Zend PHP” here, but I’m a little bit uneasy about having Zend in the name. Perhaps “the PHP.net implementation”? “PHP Group implementation”? “PHP reference implementation”?

    We could take a leaf from Python’s book and call it CPHP :)
    Or ZPHP? Implying the PHP implementation built on Zend, but not directly
    using the Zend trademark?
  • Andrea Faulds at Jul 24, 2014 at 2:51 pm

    On 24 Jul 2014, at 15:44, Rowan Collins wrote:

    Or ZPHP? Implying the PHP implementation built on Zend, but not directly using the Zend trademark?
    I like that suggestion. Reminds me of my CPHP one, but it makes more sense.

    So we’d have PHP 5.6 and ZPHP 5.6.1 (ZPHP would track major and minor spec versions). That could work, right?

    --
    Andrea Faulds
    http://ajf.me/
  • Pierre Joye at Jul 24, 2014 at 6:28 pm

    On Thu, Jul 24, 2014 at 4:44 PM, Rowan Collins wrote:
    Andrea Faulds wrote (on 24/07/2014):
    On 24 Jul 2014, at 14:40, Rowan Collins wrote:

    Incidentally, that's another question: some people like to make clear
    that the Zend Engine isn't actually the language implementation, it just
    *powers* the implementation. In which case, what *should* the implementation
    be called?
    That’s actually an important question. I always tend to say “Zend PHP”
    here, but I’m a little bit uneasy about having Zend in the name. Perhaps
    “the PHP.net implementation”? “PHP Group implementation”? “PHP reference
    implementation”?

    We could take a leaf from Python’s book and call it CPHP :)

    Or ZPHP? Implying the PHP implementation built on Zend, but not directly
    using the Zend trademark?
    Call it php.net or something like that, Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Rowan Collins at Jul 24, 2014 at 7:29 pm

    On 24/07/2014 19:28, Pierre Joye wrote:
    We could take a leaf from Python’s book and call it CPHP :)

    Or ZPHP? Implying the PHP implementation built on Zend, but not directly
    using the Zend trademark?
    Call it php.net or something like that,
    The problem with php.net is that it's also the name of the website, so
    it still doesn't unambiguously identify the implementation/distribution
    as opposed to all manner of other things that are organised via that
    site. It would be nice to have a snappy way of referring to it without
    resort to awkward phrases like "the php.net implementation of PHP".

    There's also the awkward fact that in other circumstances, a ".net"
    suffix would imply an implementation for the .net framework, which
    instead exists under the name Phalanger.
    Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.
    The idea was that "ZPHP" is PHP running on top of the Zend Engine, in
    the same way that "JRuby" is Ruby running on top of the JVM, and
    "CPython" is Python implemented in C. In my mind, it doesn't imply any
    connection to the company of the same name - especially if we're only
    borrowing its first letter - but perhaps others would see that differently.

    The only other defining feature I can think of is that it's the original
    and reference implementation, so a name suggesting that might work, like
    "PHP Prime" or "proto-PHP" (somebody may be able to think of something
    better with the same thought behind it...)

    The only other way to avoid saying "PHP 5.6.1 is an implementation of
    PHP 5.6" would be to call the specification itself something other than
    PHP, as with "POSIX" and "ECMAScript". I'm not at all keen on that idea,
    though.

    At the end of the day, we can muddle through, but it might make certain
    discussions and documentation clearer if the two can be clearly
    distinguished.

    --
    Rowan Collins
    [IMSoP]
  • Sara Golemon at Jul 24, 2014 at 7:38 pm

    On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins wrote:
    Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.
    The idea was that "ZPHP" is PHP running on top of the Zend Engine, in the
    same way that "JRuby" is Ruby running on top of the JVM, and "CPython" is
    Python implemented in C. In my mind, it doesn't imply any connection to the
    company of the same name - especially if we're only borrowing its first
    letter - but perhaps others would see that differently.
    We (HHVM) ran into this issue as well. We'd talk about the way PHP
    (the reference implementation) does something and needed to
    disambiguate it from PHP (the language syntax). Prior to my joining
    the project "Zend" was the go-to moniker for this. Since I've seen
    that go down very poorly many times in the past (who here remembers
    the ZendCon where they included "Zend === PHP" on their marketing
    materials?) I pushed the team towards saying "PHP5" when referring to
    the implementation, and "PHP" when referring to the language syntax.

    That's not really a solution for us (PHP), but I do think the issue of
    separating the language from the implementation is useful, even if our
    (PHP) implementation of PHP (syntax) is and will always be the
    de-facto reference implementation.

    -Sara

    P.S. - Pronouns are getting hard, yo.
  • Zeev Suraski at Jul 24, 2014 at 8:11 pm

    We (HHVM) ran into this issue as well. We'd talk about the way PHP (the
    reference implementation) does something and needed to disambiguate it
    from
    PHP (the language syntax).
    I think it's easy enough to talk about 'PHP' and the 'PHP language
    specification' or shorten it up as 'PHP spec'.

    Other opensource languages that have multiple implementations, still have
    the 'official' release with the original name, while other implementations
    have separate, different names that implement 'the XYZ language' or 'the
    ABC spec'.

    E.g., there's Jython, Cython, PyPy - but the original Python is still
    Python.

    Whatever php.net ships, be it based on ZE, hhvm or something else, should be
    called PHP. It's a lot more than just something that implements the spec -
    it's the codebase, build process, extensions, SAPI modules, performance,
    memory footprint, bugs, misfeatures, etc. etc. - everything that has to do
    with the implementation.
    moniker for this. Since I've seen that go down very poorly many times in
    the
    past (who here remembers the ZendCon where they included "Zend === PHP"
    on their marketing
    materials?)
    I don't recall if it was === or 'is', but regardless, the meaning was
    absolutely 'Zend is PHP' (as in everything Zend does is PHP), and not 'PHP
    is Zend'. Regardless, since it was clearly misunderstood by many people we
    stopped using it :)

    Zeev
  • Andrea Faulds at Jul 24, 2014 at 8:19 pm

    On 24 Jul 2014, at 21:12, Zeev Suraski wrote:

    Other opensource languages that have multiple implementations, still have
    the 'official' release with the original name, while other implementations
    have separate, different names that implement 'the XYZ language' or 'the
    ABC spec'.

    E.g., there's Jython, Cython, PyPy - but the original Python is still
    Python.
    Python might be a poor example. The “original Python” is called CPython.

    In technical discussions it would be very useful to have a proper name for the vanilla implementation, even though most people are going to call it PHP anyway.
    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 24, 2014 at 8:23 pm
    CPython is the name of the implementation, but python.org offers you to
    download Python, not CPython. CPython is an internal name kind of like
    php-src (more or less). In fact, as an average end user, you'd not know
    about CPython at all.

    Jython, JyJy, etc. - don't call themselves 'Python', they're
    implementations of the Python language.

    Zeev
    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 11:19 PM
    To: Zeev Suraski
    Cc: Sara Golemon; Rowan Collins; PHP internals
    Subject: Re: [PHP-DEV] PHP Language Specification

    On 24 Jul 2014, at 21:12, Zeev Suraski wrote:

    Other opensource languages that have multiple implementations, still
    have the 'official' release with the original name, while other
    implementations have separate, different names that implement 'the XYZ
    language' or 'the ABC spec'.

    E.g., there's Jython, Cython, PyPy - but the original Python is still
    Python.
    Python might be a poor example. The "original Python" is called CPython.

    In technical discussions it would be very useful to have a proper name for the
    vanilla implementation, even though most people are going to call it PHP
    anyway.
    --
    Andrea Faulds
    http://ajf.me/

  • Andrea Faulds at Jul 24, 2014 at 8:26 pm

    On 24 Jul 2014, at 21:23, Zeev Suraski wrote:

    CPython is the name of the implementation, but python.org offers you to
    download Python, not CPython. CPython is an internal name kind of like
    php-src (more or less). In fact, as an average end user, you'd not know
    about CPython at all.
    Of course. So far as users care, CPython is Python. So far as users care, Zend PHP/ZPHP/CPHP/php-src/vanilla PHP/whatever is PHP.

    However, from an internals perspective, we need to be able to distinguish the two and this becomes particularly important now due to HHVM and the specification.

    So, we should decide on a name for the original PHP implementation.
    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 24, 2014 at 8:32 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 11:26 PM
    To: Zeev Suraski
    Cc: Sara Golemon; Rowan Collins; PHP internals
    Subject: Re: [PHP-DEV] PHP Language Specification


    On 24 Jul 2014, at 21:23, Zeev Suraski wrote:

    However, from an internals perspective, we need to be able to
    distinguish the
    two and this becomes particularly important now due to HHVM and the
    specification.

    So, we should decide on a name for the original PHP implementation.
    Ok, maybe I missed the context, and if I did apologies for that. Are you
    talking about a standard way of discussing it on internals@ when we talk
    about the spec and different implementations of it?

    In that case, my vote (in the risk of agreeing with someone I almost never
    agree with) would be calling it 'php.net PHP', as that's exactly what it
    is. php.net is not just the website but all of the php.net
    infrastructure, the codebase, bug tracking system, etc. - seems like the
    most accurate name for it.

    Zeev
  • Andrea Faulds at Jul 24, 2014 at 8:43 pm

    On 24 Jul 2014, at 21:32, Zeev Suraski wrote:

    Ok, maybe I missed the context, and if I did apologies for that. Are you
    talking about a standard way of discussing it on internals@ when we talk
    about the spec and different implementations of it?
    Yeah, sorry if I didn’t make myself clear. There are various unofficial internal names for the original PHP implementation including “Zend PHP”, and I think we should settle on one for internal use. We can have it be the “nickname”, much like CPython is the nickname of the original Python implementation.
    In that case, my vote (in the risk of agreeing with someone I almost never
    agree with) would be calling it 'php.net PHP', as that's exactly what it
    is. php.net is not just the website but all of the php.net
    infrastructure, the codebase, bug tracking system, etc. - seems like the
    most accurate name for it.
    “PHP.net PHP” isn’t the nicest of names. I think CPHP, analogous to CPython is maybe the best of the available options.

    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 24, 2014 at 8:47 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 11:44 PM
    To: Zeev Suraski
    Cc: Sara Golemon; Rowan Collins; PHP internals
    Subject: Re: [PHP-DEV] PHP Language Specification


    "PHP.net PHP" isn't the nicest of names. I think CPHP, analogous to
    CPython is
    maybe the best of the available options.
    If it's for internal discussion purposes, it doesn't matter if it's the
    nicest of names. php.net PHP is an accurate description and there's no
    reason to create a new 'brand' here.

    We saw how much time it took us to decide about a version number, let's
    not waste cycles on coming up for a name for something that has been named
    for over 15 years.

    Zeev
  • Andrea Faulds at Jul 24, 2014 at 8:50 pm

    On 24 Jul 2014, at 21:47, Zeev Suraski wrote:

    We saw how much time it took us to decide about a version number, let's
    not waste cycles on coming up for a name for something that has been named
    for over 15 years.
    I’d contend CPHP hasn’t been named for 15 years as it has had no name for the implementation itself.

    Regardless, I’m going to start using CPHP myself and hope it catches on. Though short of adopting a name for the implementation officially (even if it’s just a “nickname”), this problem will continue to exist, and people will keep having to add contract-style definitions to the start of documents explaining what the term they’ve invented to refer to the original implementation means.

    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 24, 2014 at 8:56 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 11:51 PM
    To: Zeev Suraski
    Cc: PHP internals
    Subject: Re: [PHP-DEV] PHP Language Specification


    I'd contend CPHP hasn't been named for 15 years as it has had no name for the
    implementation itself.
    I have no idea what CPHP is, but we've had PHP named for the last 15+
    years, and other implementations of it (like Quercus, Phalanger, etc. and
    now hhvm). Nothing changed today.

    Either way I'm going to end my participation in this part of the thread
    here.

    Zeev
  • Ferenc Kovacs at Jul 24, 2014 at 8:41 pm
    On Thu, Jul 24, 2014 at 10:26 PM, Andrea Faulds wrote:
    On 24 Jul 2014, at 21:23, Zeev Suraski wrote:

    CPython is the name of the implementation, but python.org offers you to
    download Python, not CPython. CPython is an internal name kind of like
    php-src (more or less). In fact, as an average end user, you'd not know
    about CPython at all.
    Of course. So far as users care, CPython is Python. So far as users care,
    Zend PHP/ZPHP/CPHP/php-src/vanilla PHP/whatever is PHP.

    However, from an internals perspective, we need to be able to distinguish
    the two and this becomes particularly important now due to HHVM and the
    specification.

    So, we should decide on a name for the original PHP implementation.
    --
    Andrea Faulds
    http://ajf.me/
    I still think that Python/CPython is a good example, it shows how confusing
    can it be when the reference implementation and the language has a
    different name:
    http://stackoverflow.com/questions/17130975/python-vs-cpython
    As Zeev mentioned the CPython name is mostly just used for to refer to the
    vanilla implementation when comparing to others, but the codebase of it
    still refer to itself as python.
    I think the only case when you can have a separate name for the reference
    implementation than the name of the language is at the start, if you do it
    anytime later, it will cause some headaches, but it isn't impossible as we
    can see from the python example.

    Ruby is also an interesting example, there are also a bunch of alternative
    implementations, the reference implementation refers to itself as ruby, and
    when comparing it to other implementations it is either called MRI (Matz's
    Ruby Interpreter) or CRuby.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Rowan Collins at Jul 24, 2014 at 8:29 pm

    On 24/07/2014 21:12, Zeev Suraski wrote:
    I don't recall if it was === or 'is', but regardless, the meaning was
    absolutely 'Zend is PHP' (as in everything Zend does is PHP), and not 'PHP
    is Zend'. Regardless, since it was clearly misunderstood by many people we
    stopped using it :)
    See also the German national anthem, in which "Deutschland ueber alles"
    was intended to mean "consider German unification above your local
    power", not "Germany should rule the world", although it's no stretch to
    assume that Hitler favoured the latter interpretation. The current
    anthem consists only of the less easily reinterpreted third verse.

    Damn, Godwin's Law, sorry all!
    :(

    --
    Rowan Collins
    [IMSoP]
  • Larry Garfield at Jul 25, 2014 at 4:25 pm

    On 7/24/14, 2:38 PM, Sara Golemon wrote:
    On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins wrote:
    Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.
    The idea was that "ZPHP" is PHP running on top of the Zend Engine, in the
    same way that "JRuby" is Ruby running on top of the JVM, and "CPython" is
    Python implemented in C. In my mind, it doesn't imply any connection to the
    company of the same name - especially if we're only borrowing its first
    letter - but perhaps others would see that differently.
    We (HHVM) ran into this issue as well. We'd talk about the way PHP
    (the reference implementation) does something and needed to
    disambiguate it from PHP (the language syntax). Prior to my joining
    the project "Zend" was the go-to moniker for this. Since I've seen
    that go down very poorly many times in the past (who here remembers
    the ZendCon where they included "Zend === PHP" on their marketing
    materials?) I pushed the team towards saying "PHP5" when referring to
    the implementation, and "PHP" when referring to the language syntax.

    That's not really a solution for us (PHP), but I do think the issue of
    separating the language from the implementation is useful, even if our
    (PHP) implementation of PHP (syntax) is and will always be the
    de-facto reference implementation.

    -Sara

    P.S. - Pronouns are getting hard, yo.
    Until we figure it out, I will be referring to the current common
    implementation as "Zippy". Hopefully it catches on.

    --Larry Garfield
  • Chris Wright at Jul 26, 2014 at 9:55 pm

    On 25 July 2014 17:25, Larry Garfield wrote:
    On 7/24/14, 2:38 PM, Sara Golemon wrote:

    On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins <rowan.collins@gmail.com>
    wrote:
    Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.
    The idea was that "ZPHP" is PHP running on top of the Zend Engine, in the
    same way that "JRuby" is Ruby running on top of the JVM, and "CPython" is
    Python implemented in C. In my mind, it doesn't imply any connection to
    the
    company of the same name - especially if we're only borrowing its first
    letter - but perhaps others would see that differently.
    We (HHVM) ran into this issue as well. We'd talk about the way PHP
    (the reference implementation) does something and needed to
    disambiguate it from PHP (the language syntax). Prior to my joining
    the project "Zend" was the go-to moniker for this. Since I've seen
    that go down very poorly many times in the past (who here remembers
    the ZendCon where they included "Zend === PHP" on their marketing
    materials?) I pushed the team towards saying "PHP5" when referring to
    the implementation, and "PHP" when referring to the language syntax.

    That's not really a solution for us (PHP), but I do think the issue of
    separating the language from the implementation is useful, even if our
    (PHP) implementation of PHP (syntax) is and will always be the
    de-facto reference implementation.

    -Sara

    P.S. - Pronouns are getting hard, yo.

    Until we figure it out, I will be referring to the current common
    implementation as "Zippy". Hopefully it catches on.
    Sounds like a Zend ImPlementation of PYthon...
  • Rowan Collins at Jul 27, 2014 at 5:24 pm

    On 26/07/2014 22:55, Chris Wright wrote:
    On 25 July 2014 17:25, Larry Garfield wrote:
    On 7/24/14, 2:38 PM, Sara Golemon wrote:
    On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins <rowan.collins@gmail.com>
    wrote:
    Zend is only one of many
    contributors. Yes, the engine is still named Zend Engine but the
    language has been improved by many php.net contributors.
    The idea was that "ZPHP" is PHP running on top of the Zend Engine, in the
    same way that "JRuby" is Ruby running on top of the JVM, and "CPython" is
    Python implemented in C. In my mind, it doesn't imply any connection to
    the
    company of the same name - especially if we're only borrowing its first
    letter - but perhaps others would see that differently.
    We (HHVM) ran into this issue as well. We'd talk about the way PHP
    (the reference implementation) does something and needed to
    disambiguate it from PHP (the language syntax). Prior to my joining
    the project "Zend" was the go-to moniker for this. Since I've seen
    that go down very poorly many times in the past (who here remembers
    the ZendCon where they included "Zend === PHP" on their marketing
    materials?) I pushed the team towards saying "PHP5" when referring to
    the implementation, and "PHP" when referring to the language syntax.

    That's not really a solution for us (PHP), but I do think the issue of
    separating the language from the implementation is useful, even if our
    (PHP) implementation of PHP (syntax) is and will always be the
    de-facto reference implementation.

    -Sara

    P.S. - Pronouns are getting hard, yo.
    Until we figure it out, I will be referring to the current common
    implementation as "Zippy". Hopefully it catches on.
    Sounds like a Zend ImPlementation of PYthon...
    All I could think was "in that case, who's Bungle?" ;)

    --
    Rowan Collins
    [IMSoP]
  • Ferenc Kovacs at Jul 24, 2014 at 2:55 pm
    On Thu, Jul 24, 2014 at 4:28 PM, Andrea Faulds wrote:
    On 24 Jul 2014, at 14:40, Rowan Collins wrote:

    Incidentally, that's another question: some people like to make clear
    that the Zend Engine isn't actually the language implementation, it just
    *powers* the implementation. In which case, what *should* the
    implementation be called?

    That’s actually an important question. I always tend to say “Zend PHP”
    here, but I’m a little bit uneasy about having Zend in the name. Perhaps
    “the PHP.net implementation”? “PHP Group implementation”? “PHP reference
    implementation”?

    We could take a leaf from Python’s book and call it CPHP :)

    --
    Andrea Faulds
    http://ajf.me/
    I would say reference implementation or vanilla php.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Zeev Suraski at Jul 24, 2014 at 8:01 pm
    I think we're overcomplicating things a bit...

    First, as someone from Zend, I never ever call PHP "Zend PHP". PHP is
    hardly just the Zend Engine, but also the extensions, SAPI modules, tests,
    etc - everything that people with php.net accounts work on. In fact if I
    hear someone saying 'Zend PHP' I'd always correct them, although it's
    pretty uncommon. If I ever do need to qualify it vs. other
    implementations, then it's always 'the php.net PHP', not anything else.
    php.net in that regard isn't a website - it's the whole php.net developer
    community.

    The name of this implementation should absolutely remain PHP, not CPHP or
    ZPHP or anything else, and it's in fact the only piece of software that
    may call itself PHP as per the PHP license.

    I think that the language spec initiative is a great initiative, but let's
    not get carried away and start turning things upside down. This would be
    the 'PHP language specification', not 'PHP'. PHP would ideally adhere to
    it. Other implementation (such as hhvm) would probably adhere to them as
    well - but they would still not be named 'PHP', but rather,
    implementations of the PHP language or the PHP language spec. This is
    consistent with mostly all of the other open source scripting languages
    out there.

    When we talk about a bug in PHP 5.6.2 or a new feature in PHP 9.9, it will
    absolutely refer to that thing you download from www.php.net (or packages
    based off of it) - not the language spec.

    Zeev
    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 5:29 PM
    To: Rowan Collins
    Cc: internals@lists.php.net
    Subject: Re: [PHP-DEV] PHP Language Specification

    On 24 Jul 2014, at 14:40, Rowan Collins wrote:

    Incidentally, that's another question: some people like to make clear
    that
    the Zend Engine isn't actually the language implementation, it just *powers*
    the implementation. In which case, what *should* the implementation be
    called?

    That's actually an important question. I always tend to say "Zend PHP" here,
    but I'm a little bit uneasy about having Zend in the name. Perhaps "the
    PHP.net implementation"? "PHP Group implementation"? "PHP reference
    implementation"?

    We could take a leaf from Python's book and call it CPHP :)

    --
    Andrea Faulds
    http://ajf.me/





    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
    http://www.php.net/unsub.php
  • Andrea Faulds at Jul 24, 2014 at 8:03 pm

    On 24 Jul 2014, at 21:00, Zeev Suraski wrote:

    I think that the language spec initiative is a great initiative, but let's
    not get carried away and start turning things upside down. This would be
    the 'PHP language specification', not 'PHP'. PHP would ideally adhere to
    it. Other implementation (such as hhvm) would probably adhere to them as
    well - but they would still not be named 'PHP', but rather,
    implementations of the PHP language or the PHP language spec. This is
    consistent with mostly all of the other open source scripting languages
    out there.
    This is unhelpful, however, as it leaves PHP being ambiguous as to whether it means the implementation or the spec.

    You know, the git repository is called php-src. Why don’t we call the implementation php-src?

    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 24, 2014 at 8:18 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Thursday, July 24, 2014 11:04 PM
    To: Zeev Suraski
    Cc: Rowan Collins; internals@lists.php.net
    Subject: Re: [PHP-DEV] PHP Language Specification

    On 24 Jul 2014, at 21:00, Zeev Suraski wrote:

    I think that the language spec initiative is a great initiative, but
    let's not get carried away and start turning things upside down. This
    would be the 'PHP language specification', not 'PHP'. PHP would
    ideally adhere to it. Other implementation (such as hhvm) would
    probably adhere to them as well - but they would still not be named
    'PHP', but rather, implementations of the PHP language or the PHP
    language spec. This is consistent with mostly all of the other open
    source scripting languages out there.
    This is unhelpful, however, as it leaves PHP being ambiguous as to
    whether it
    means the implementation or the spec.
    No, there's no ambiguity at all - 'PHP' is the implementation, as it
    always has been. 'PHP language specification' or 'PHP spec' for short is
    the specification. Absolutely no ambiguity.
    You know, the git repository is called php-src. Why don't we call the
    implementation php-src?
    Well, one reason is that it would be a horrible, horrible name (imagine us
    "Happy to announce php-src 5.6!", come on). But another is there's really
    absolutely no reason to change the name of PHP to anything at all. There
    would be the PHP spec, and there would be PHP.

    Zeev

Related Discussions