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.
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
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,
-SaraP.S. - Apologies if you got this twice. But the version I sent with an
attachment looks like it got stripped by the list server.
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.
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/
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. :)
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/
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
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
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/
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
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
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/
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.
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/
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?
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
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/
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!
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/
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]
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/
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
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/
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.
- 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). - 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. - 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/
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]
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/
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
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 [mailto:ajf@ajf.me]
Sent: Thursday, July 24, 2014 5:29 PM
To: Rowan Collins
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP Language SpecificationIncidentally, 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/--
To unsubscribe,
visit:
http://www.php.net/unsub.php
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/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Thursday, July 24, 2014 11:04 PM
To: Zeev Suraski
Cc: Rowan Collins; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP Language SpecificationI 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
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.
So PHP is variously the language (as in PHP language specification) and an implementation (as in PHP).
There is definitely an ambiguity. We need to be able to distinguish between PHP (the language/specification) and PHP (the implementation).
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.
What does PHP mean here? The language? The vanilla implementation?
--
Andrea Faulds
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Thursday, July 24, 2014 11:21 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP Language SpecificationNo, 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.So PHP is variously the language (as in PHP language specification) and
an
implementation (as in PHP).
Not at all. 'PHP' is the implementation, what you download off of
php.net. 'PHP language specification' is the specification. That's
exactly what I wrote before so I'm not sure it'll be clearer now, but I
fail to see what's hard to understand about it :)
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.What does PHP mean here? The language? The vanilla implementation?
PHP along depends on the context. We're humans, and we use the same words
to mean different things in different context.
"Download PHP" -> download the php.net implementation
"PHP 5.6" -> the php.net implementation
"PHP spec" -> the PHP
"The PHP ecosystem" -> everything that has anything to do with PHP
"A PHP developer" -> someone who can develop in PHP
It's really not complicated, let's not pretend it is.
Zeev
"PHP 5.6" -> the php.net implementation
This is the one that led us down this particular path: the spec will
necessarily have versions of its own, and the obvious thing to do is to
make them match the minor versions of the reference implementation; so
"PHP 5.6" could mean "a php.net 5.6.x release" or the language
specification matching that.
To be honest, one of the things I was thinking about was the fact that
the "Implementations" line on this Wikipedia template has no entry for
the default implementation: https://en.wikipedia.org/wiki/Template:PHP
Which is definitely too trivial to spend much energy debating.
--
Rowan Collins
[IMSoP]
I think we're overcomplicating things a bit...
...
absolutely refer to that thing you download from www.php.net (or packages
based off of it) - not the language spec.
I totally agree with you here. PHP is and remains php.net's PHP.
Cheers,
Pierre
Maybe there’s hope for the middle east J
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, July 24, 2014 11:29 PM
To: Zeev Suraski
Cc: Andrea Faulds; PHP internals; Rowan Collins
Subject: RE: [PHP-DEV] PHP Language Specification
I think we're overcomplicating things a bit...
...
absolutely refer to that thing you download from www.php.net (or packages
based off of it) - not the language spec.
I totally agree with you here. PHP is and remains php.net's PHP.
Cheers,
Pierre
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.
Or if an implementation has a bug, which will be the most common usecase
I think, no?
--
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/
Ivan Enderlin @ Hoa wrote (on 25/07/2014):
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.
Or if an implementation has a bug, which will be the most common
usecase I think, no?
Implementation release 5.6.0 would attempt to meet specification 5.6;
if it contained a bug, release 5.6.1 would be against the same
specification, and hopefully a better implementation of it.
See my previous post:
http://marc.info/?l=php-internals&m=140615333501569&w=2
Hi!
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.
Thank you Sara and Facebook team for doing something we've been talking
about for more than a decade and before that nobody actually attempting
to do. I think it is a great development and I hope to see the first
version soon.
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.
I would propose choosing some collaborative platform for managing it,
something like Google Docs (suggestions about best platform ever for
that are welcome :) so that people could comment on specific parts and
keep track of what is the current state and what has been discussed.
Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).
I'd also advocate creating a workgroup and a mailing list for it to
discuss the spec and to work on it and other things like ones above there.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On Tue, Jul 22, 2014 at 3:28 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
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.Thank you Sara and Facebook team for doing something we've been talking
about for more than a decade and before that nobody actually attempting
to do. I think it is a great development and I hope to see the first
version soon.
+1
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.I would propose choosing some collaborative platform for managing it,
something like Google Docs (suggestions about best platform ever for
that are welcome :) so that people could comment on specific parts and
keep track of what is the current state and what has been discussed.
+1
Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).I'd also advocate creating a workgroup and a mailing list for it to
discuss the spec and to work on it and other things like ones above there.
+1
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Stas Malyshev wrote (on 22/07/2014):
Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).
Something like Wikipedia's "Create a Book" feature perhaps? [1] That can
be set up on any MediaWiki install with the right extensions. [2]
It looks like DokuWiki (which I think wiki.php.net is running?) has a
similar plugin. [3] No idea if it's any good, but it looks like it's
reasonably actively maintained.
[1] https://en.wikipedia.org/wiki/Help:Books
[2] https://www.mediawiki.org/wiki/Extension:Collection
[3] https://www.dokuwiki.org/plugin:bookcreator
Regards,
Rowan Collins
[IMSoP]
Rowan Collins wrote:
Stas Malyshev wrote (on 22/07/2014):
Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).Something like Wikipedia's "Create a Book" feature perhaps? [1] That can
be set up on any MediaWiki install with the right extensions. [2]It looks like DokuWiki (which I think wiki.php.net is running?) has a
similar plugin. [3] No idea if it's any good, but it looks like it's
reasonably actively maintained.[1] https://en.wikipedia.org/wiki/Help:Books
[2] https://www.mediawiki.org/wiki/Extension:Collection
[3] https://www.dokuwiki.org/plugin:bookcreator
Another idea would be a Git repository with the specification as markdown files. This would allow creating Pull Requests via GitHub.
Best regards,
Christian
Hi!
Another idea would be a Git repository with the specification as
markdown files. This would allow creating Pull Requests via GitHub.
I think facilitating discussion and feedback is more important than
change tracking for now, but given github also has issues facility it
may actually work. I'm not sure if markdown is expressive enough though
(e.g. it does not have sub/superscripts AFAIK).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
Hi!
Another idea would be a Git repository with the specification as
markdown files. This would allow creating Pull Requests via GitHub.I think facilitating discussion and feedback is more important than
change tracking for now, but given github also has issues facility it
may actually work. I'm not sure if markdown is expressive enough though
(e.g. it does not have sub/superscripts AFAIK).
maybe some of the symfony folks can say something about that? They are hosting their docs on github, using reStructuredText and it seems to work reasonably well?
Cheers
Jannik
I have a thought about the spec.
I work on Yii framework and the team building it has a great policy - if
your changes to the code require changes to the documentation - you are
required to update the docs. No docs changes - no merge.
The most up to date documentation I have ever seen.
Maybe for the PHP Spec to be relevant there needs to be a rule enforced
like in Yii?
Arvids.
I would propose choosing some collaborative platform for managing it,
something like Google Docs (suggestions about best platform ever for
that are welcome :) so that people could comment on specific parts and
keep track of what is the current state and what has been discussed.Alternatively, we could do a wiki maybe but the problem there is that it
is hard to export (unless anybody knows wiki setups that can be easily
exported into single document).
This is another can of worms, and perhaps an example of why the current
php website structure is such a problem :(
Using different tools for different areas of the website, laying off
elements to third party services and then relying on other third party
services to provide a usable 'website' search ... which only partially
works when you select a different language.
Moving elements of the website into a more coherent whole is yet another
project that is long overdue and since we are DESIGNING the very
software that creates these facilities, it should not be difficult?
The current user manual should be a wiki with sections for rfc
management, adding comments, managing history of changes and so on. The
Language Specification is simply an extension of that as is the sort of
internal code documentation we are currently asking for.
DokuWiki is sort of functional, but as has been indicated, cloning a
copy of the history on another machine is not possible! Keeping the
material in a DVCS sort of works, but these are not designed for
document maintenance? I keep looking at importing the whole lot into a
database which can the be provided as a daily backup, which adds the
ability to search both current views of the material and back through
history for changes. Moving everything into a framework which can manage
both translations and integral cross linking, and gives a single front
end to everything on the website ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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
Nice push Sara.
Thank you.
Julien.P
I know this is a peak at the new documentation, but it flagged up
something when I was scanning through.
switch Statement ...
I have always put the 'default:' as the last item in the list since it's
what is left after processing all the other options and one may or may
not have fallen out.
So I went to http://php.net/docs.php to check out there, and putting
'switch' in the search box it's not then obvious that one HAS to hit
enter to get the function switch? It would be nice if 'switch' appeared
in the drop down list?
Anyway, having then found the right page, some of the subtleties
documented in the spec are not covered in the manual. In fact I don't
think that what is described in the spec is actually what happens in
code? This is perhaps the reason that a formal spec is long overdue. The
manual says the statements are actioned in order, and certainly that is
what I expect so I can add bits in the flow through, but does the switch
statement know that a value is not listed as a case prior to scanning
the code?
Also included in the spec is the 'alternative syntax' which should
perhaps be tagged differently going forward? I know both styles of
working can be randomly mixed, but some sort of 'grouping' for style
variations would enhance the spec's usability.
Switching back to managing the spec content, and integrating it with
other material, as an example, a link on the
php.net/manual/en/control-structures.switch.php to the relevant section
in the spec is perhaps just to obvious, but is another example of where
a central repository for content just makes common sense ... We have
asked in the past the the manual pages are updated when RFC's are
created, so pull all of that together in the one process? I'm just not
sure 'git' is the right container for doing it? Moving the content of
the dokuwiki into git would at least allow that to be used and mirrored
as other materiel.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I have always put the 'default:' as the last item in the list since it's
what is left after processing all the other options and one may or may
not have fallen out.
This is intuitive, and arguably good coding style, but not necessary as
switch statements are implemented in PHP.
Anyway, having then found the right page, some of the subtleties
documented in the spec are not covered in the manual. In fact I don't
think that what is described in the spec is actually what happens in
code? This is perhaps the reason that a formal spec is long overdue. The
manual says the statements are actioned in order, and certainly that is
what I expect so I can add bits in the flow through, but does the switch
statement know that a value is not listed as a case prior to scanning
the code?
I think the specification does quite a good job of describing the
abstract behaviour. Whether this is literally how it is implemented in
the engine doesn't actually matter, as long as the result is as though
it is the case.
These seem to be the key points:
- "If a switch contains more than one case label whose values compare
equal to the controlling expression, the first in lexical order is
[considered] the match." (this is the only way in which the ordering of
labels makes any difference; a compiled form might involve some form of
lookup table, but it must follow this rule in the case of duplicate "keys") - "If there is no match, then if there is a default label, control
transfers to the statement following that" (i.e. the selection of a
default label happens after all other options have been exhausted, not
when the default label is encountered)
The fact that code falls through from one case to another is separate
from the selection of the label to start execution at. It is
equivalent to think of all case labels being removed from the code as
soon as one is selected: control continues until it reaches a "break"
statement or the end of the switch.
Here's an example to play around with: http://3v4l.org/rm72I
P.S. Whatever form this spec is eventually distributed in, I hope it
doesn't contain whatever markup/misfeature is causing Adobe Reader to
insert quote"marks"between"every"word when I copy and paste from it!
--
Rowan Collins
[IMSoP]
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.
Progress is being made on getting it all into a collaborative format.
Our documentation guy is currently favoring markdown as an initial
format which is able to express everything currently in the spec, and
he's planning to build some rendering scripts that'll be able to
produce other formats from it if we want to swap later. Here's a
sample of what that ends up looking like:
https://pbs.twimg.com/media/BtUkSVLCEAA3Lfq.png:large
The plan at the moment is to put it at
https://github.com/phplang/php-spec with a CC0 license (public domain)
and give push karma to those who currently have ZendEngine karma.
This lets us react quickly to PRs in this early part of the draft,
while tying "ownership" of the language to those who have been writing
it. For portability, we'll be pushing renderings of the spec to a
Github Pages site at http://phplang.github.io
-Sara
Hi!
Progress is being made on getting it all into a collaborative format.
Our documentation guy is currently favoring markdown as an initial
format which is able to express everything currently in the spec, and
he's planning to build some rendering scripts that'll be able to
produce other formats from it if we want to swap later. Here's a
sample of what that ends up looking like:
https://pbs.twimg.com/media/BtUkSVLCEAA3Lfq.png:large
This looks pretty good. Thanks!
Is it also possible to pub description of how to render it on
wiki.php.net so that if someone prepares a big patch they'd be able to
test they didn't mess up before committing?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Is it also possible to pub description of how to render it on
wiki.php.net so that if someone prepares a big patch they'd be able to
test they didn't mess up before committing?
The repo layout he's working on includes a tools/ directory for
generating output, so yeah. One would be able to run a quick script
to produce HTML or something verifiable. If it stays Markdown as the
source format, then the PR will of course also be visible in the
branch straight from github.
-Sara