Re: [PHP-DEV] PHP Language Specification

[Rowan Tommins]

On 07/05/2021 09:10, Nikita Popov wrote:

If we want to include "writing documentation"
as part of the change process, then it would be much more valuable to write
documentation for php.net, which is used by hundreds of thousands of
developers, rather than the language specification, which is used by a
handful at best.



I agree with this.

The reality is, the specification is just another form of documentation. 
When it was written, there was a realistic prospect of two competing 
implementations needing to agree on new features, but that never 
happened, so if the spec doesn't agree with the implementation, it's 
always the spec that's wrong.


If we want the behaviour of the language to be better documented, we 
have existing places for that:


* Incorporate formal descriptions from the language spec into the 
manual. Maybe we need a way of embedding grammar snippets into 
appropriate chapters.
* Document behaviour in edge cases - defaults, error conditions, 
interactions of options, etc. You don't have to be writing an 
implementation to want to know that stuff.
* Encourage, or require, contributors to write some basic documentation 
of new features. We have bundled functions and options without even a 
single sentence in the manual.
* Write tests, and label them clearly. If anyone wants to write an 
alternative implementation, they can run the test suite against it.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Nikita Popov]

On Thu, May 6, 2021 at 4:01 PM Christoph M. Becker 
wrote:

> Hi all,
>
> I wonder what to do with the PHP Language Specification[1].  Apparently,
> the repo is abandoned (last commit was more than a year ago, although
> PHP 8 changed quite some stuff).  If we don't have the bandwidth to
> maintain it, we should mark it as unmaintained, and maybe some of the
> information could be moved to the PHP manual  (I quite like the strict
> syntax specification, which the manual almost completely lacks).


To offer a counter-opinion to what others said: Yes, we should absolutely
discontinue the language specification.

The thing is, this is a project without purpose, or at least no purpose
that I am able to discern. Without a very significant amount of effort, the
language specification is so far removed from being either accurate or
complete, that it is of very limited usefulness to alternative
implementations of PHP. The grammar is probably the only part that's
somewhat accurate --  and I think people can get similar mileage from just
looking at zend_language_parser.y directly, which happens to reflect the
ground truth and never get outdated.

I think the only real usefulness the language specification has right now
is that we're able to say "we have a specification".

Now, if someone does want to pick up maintenance, be my guest, but I think
requiring RFC authors or core developers to update the spec is a
misallocation of resources: If we want to include "writing documentation"
as part of the change process, then it would be much more valuable to write
documentation for php.net, which is used by hundreds of thousands of
developers, rather than the language specification, which is used by a
handful at best.

Regards,
Nikita

Re: [PHP-DEV] PHP Language Specification

[Ben Ramsey]

On 5/6/21 11:37, Larry Garfield wrote:

Is it going to be supported by people working on core?  Fantastic.  If not, 
it's going to get and stay out of date and offer not enough value for anyone to 
bother stepping up to pick up that slack.  (As we've seen.)


I think we should require RFCs that propose new or updated syntax to 
include in the body of the RFC the relevant grammar for updating the 
langspec and possibly a related PR to the php-langspec repo, as well.


Cheers,
Ben


OpenPGP_0xF9C39DC0B9698544_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP Language Specification

[Stanislav Malyshev]

Hi!


I wonder what to do with the PHP Language Specification[1].  Apparently,
the repo is abandoned (last commit was more than a year ago, although
PHP 8 changed quite some stuff).  If we don't have the bandwidth to
maintain it, we should mark it as unmaintained, and maybe some of the
information could be moved to the PHP manual  (I quite like the strict
syntax specification, which the manual almost completely lacks).


The old stuff I think is still valid, but would be nice if somebody took 
on themselves to update it. I think the spec and the manual are 
different documents, for different audiences, so having separate spec 
would be a good thing. However, we should have clear demarcation which 
parts applies to which version and which parts are missing.


--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Christoph M. Becker]

On 06.05.2021 at 18:37, Michał Marcin Brzuchalski wrote:

> czw., 6 maj 2021, 17:23 użytkownik Sara Golemon  napisał:
>
>> On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
>> michal.brzuchal...@gmail.com> wrote:
>>
>>> czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker >>>
>>> napisał:
>>>
 I wonder what to do with the PHP Language Specification[1].  Apparently,
 the repo is abandoned (last commit was more than a year ago, although
 PHP 8 changed quite some stuff).  If we don't have the bandwidth to
 maintain it, we should mark it as unmaintained, and maybe some of the
 information could be moved to the PHP manual  (I quite like the strict
 syntax specification, which the manual almost completely lacks).

>>>
>>> How much effort would it require?
>>> Is there potentially someone who could help with reviews?
>>
>> Which part? Getting it up to date and keeping it there? Or moving the
>> parts we most care about to the manual then abandoning it?
>>
>> I'm actually fairly happy either way, but it does need some TLC.  Some
>> brave soul to step up and yes, "YES! I WILL DEFEND THE LANGUAGE
>> SPECIFICATION!"  Someone with the courage to do the dirty work.  WHO WILL
>> STAND AND FIGHT?!*
>
> I can do this.
> I love language nuances and clear explanations.
> Possibly that would not be fast from my side but I believe this kind of
> project doesn't have to reflect language changes immediately when it comes
> to interpreter. Also a lot of time would spend on new content quality but I
> believe when I ask for a help with not my native English language can
> always find it.
>
> At least I'm brave enough to pick up the gauntlet.
>
> What do you say?

IMHO it is okay if the language specification doesn't reflect languages
changes "immediately", but still not reflecting some PHP 7.1 changes[1]
makes it pretty useless to me.  And of course, this raises the question
which PHP version shoud be documented?  Different branches for each
version, or maybe add comments/changelog entries?

And then there is the even more general question regarding "conforming
implementations".  How many are there?  The language specification has
mostly been written to clarify the supposed behavior for different PHP
implementations, but that doesn't seem to really matter nowadays.  Note
that the test suite has been intended to be used by all conforming
implementations, but in practice isn't used by anybody.

[1] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Larry Garfield]

On Thu, May 6, 2021, at 10:23 AM, Sara Golemon wrote:
> On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
> 
> > czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker 
> > napisał:
> >
> > > I wonder what to do with the PHP Language Specification[1].  Apparently,
> > > the repo is abandoned (last commit was more than a year ago, although
> > > PHP 8 changed quite some stuff).  If we don't have the bandwidth to
> > > maintain it, we should mark it as unmaintained, and maybe some of the
> > > information could be moved to the PHP manual  (I quite like the strict
> > > syntax specification, which the manual almost completely lacks).
> > >
> >
> > How much effort would it require?
> > Is there potentially someone who could help with reviews?
> >
> >
> Which part? Getting it up to date and keeping it there? Or moving the parts
> we most care about to the manual then abandoning it?
> 
> I'm actually fairly happy either way, but it does need some TLC.  Some
> brave soul to step up and yes, "YES! I WILL DEFEND THE LANGUAGE
> SPECIFICATION!"  Someone with the courage to do the dirty work.  WHO WILL
> STAND AND FIGHT?!*
> 
> -Sara
> 
> * I just got my second dose of the vaccine and evidently it's making me a
> bit goofy, but don't let that stop anyone from stepping up.  We all make
> PHP better together.

Having an independent specification is a good thing, but as you say it needs 
people.  It also needs a commitment from the core dev process to include 
updating it in the process.  That was always the missing link, IIRC.  
Documentation already suffers from the same problem (updates for docs are left 
for "someone else to do later" when an RFC is proposed), but at least there the 
demand for Someone(tm) to Do Something(tm) is large enough and the barrier to 
entry low enough that it mostly happens eventually, mostly.  Neither of those 
is the case for the spec, which is why it just doesn't happen.

Is it going to be supported by people working on core?  Fantastic.  If not, 
it's going to get and stay out of date and offer not enough value for anyone to 
bother stepping up to pick up that slack.  (As we've seen.)

I agree it needs to be either promoted to euthanized, one or the other.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Michał Marcin Brzuchalski]

czw., 6 maj 2021, 17:23 użytkownik Sara Golemon  napisał:

> On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker > >
>> napisał:
>>
>> > I wonder what to do with the PHP Language Specification[1].  Apparently,
>> > the repo is abandoned (last commit was more than a year ago, although
>> > PHP 8 changed quite some stuff).  If we don't have the bandwidth to
>> > maintain it, we should mark it as unmaintained, and maybe some of the
>> > information could be moved to the PHP manual  (I quite like the strict
>> > syntax specification, which the manual almost completely lacks).
>> >
>>
>> How much effort would it require?
>> Is there potentially someone who could help with reviews?
>>
>>
> Which part? Getting it up to date and keeping it there? Or moving the
> parts we most care about to the manual then abandoning it?
>
> I'm actually fairly happy either way, but it does need some TLC.  Some
> brave soul to step up and yes, "YES! I WILL DEFEND THE LANGUAGE
> SPECIFICATION!"  Someone with the courage to do the dirty work.  WHO WILL
> STAND AND FIGHT?!*
>

I can do this.
I love language nuances and clear explanations.
Possibly that would not be fast from my side but I believe this kind of
project doesn't have to reflect language changes immediately when it comes
to interpreter. Also a lot of time would spend on new content quality but I
believe when I ask for a help with not my native English language can
always find it.

At least I'm brave enough to pick up the gauntlet.

What do you say?

Cheers,
Michał Marcin Brzuchalski

>

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker 
> napisał:
>
> > I wonder what to do with the PHP Language Specification[1].  Apparently,
> > the repo is abandoned (last commit was more than a year ago, although
> > PHP 8 changed quite some stuff).  If we don't have the bandwidth to
> > maintain it, we should mark it as unmaintained, and maybe some of the
> > information could be moved to the PHP manual  (I quite like the strict
> > syntax specification, which the manual almost completely lacks).
> >
>
> How much effort would it require?
> Is there potentially someone who could help with reviews?
>
>
Which part? Getting it up to date and keeping it there? Or moving the parts
we most care about to the manual then abandoning it?

I'm actually fairly happy either way, but it does need some TLC.  Some
brave soul to step up and yes, "YES! I WILL DEFEND THE LANGUAGE
SPECIFICATION!"  Someone with the courage to do the dirty work.  WHO WILL
STAND AND FIGHT?!*

-Sara

* I just got my second dose of the vaccine and evidently it's making me a
bit goofy, but don't let that stop anyone from stepping up.  We all make
PHP better together.

Re: [PHP-DEV] PHP Language Specification

[Michał Marcin Brzuchalski]

czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker 
napisał:

> Hi all,
>
> I wonder what to do with the PHP Language Specification[1].  Apparently,
> the repo is abandoned (last commit was more than a year ago, although
> PHP 8 changed quite some stuff).  If we don't have the bandwidth to
> maintain it, we should mark it as unmaintained, and maybe some of the
> information could be moved to the PHP manual  (I quite like the strict
> syntax specification, which the manual almost completely lacks).
>
> Thoughts?
>

How much effort would it require?
Is there potentially someone who could help with reviews?

Cheers,
Michał Marcin Brzuchalski

>

[PHP-DEV] PHP Language Specification

[Christoph M. Becker]

Hi all,

I wonder what to do with the PHP Language Specification[1].  Apparently,
the repo is abandoned (last commit was more than a year ago, although
PHP 8 changed quite some stuff).  If we don't have the bandwidth to
maintain it, we should mark it as unmaintained, and maybe some of the
information could be moved to the PHP manual  (I quite like the strict
syntax specification, which the manual almost completely lacks).

Thoughts?

[1] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

On 26/07/2014 22:55, Chris Wright wrote:

On 25 July 2014 17:25, Larry Garfield la...@garfieldtech.com wrote:

On 7/24/14, 2:38 PM, Sara Golemon wrote:

On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins rowan.coll...@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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Chris Wright]

On 25 July 2014 17:25, Larry Garfield la...@garfieldtech.com wrote:
 On 7/24/14, 2:38 PM, Sara Golemon wrote:

 On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins rowan.coll...@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...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ivan Enderlin @ Hoa]

On 24/07/2014 15:40, Rowan Collins wrote:

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/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

Ivan Enderlin @ Hoa wrote (on 25/07/2014):


On 24/07/2014 15:40, Rowan Collins wrote:

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-internalsm=140615333501569w=2


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ivan Enderlin @ Hoa]

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-internalsm=140612071919140w=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/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 14:40, Rowan Collins rowan.coll...@gmail.com 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

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

Andrea Faulds wrote (on 24/07/2014):

On 24 Jul 2014, at 14:40, Rowan Collins rowan.coll...@gmail.com 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?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 15:44, Rowan Collins rowan.coll...@gmail.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ferenc Kovacs]

On Thu, Jul 24, 2014 at 4:28 PM, Andrea Faulds a...@ajf.me wrote:


 On 24 Jul 2014, at 14:40, Rowan Collins rowan.coll...@gmail.com 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

Re: [PHP-DEV] PHP Language Specification

[Pierre Joye]

On Thu, Jul 24, 2014 at 4:44 PM, Rowan Collins rowan.coll...@gmail.com wrote:
 Andrea Faulds wrote (on 24/07/2014):

 On 24 Jul 2014, at 14:40, Rowan Collins rowan.coll...@gmail.com 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins rowan.coll...@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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

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:a...@ajf.me]
 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 rowan.coll...@gmail.com 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:00, Zeev Suraski z...@zend.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@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 Specification


 On 24 Jul 2014, at 21:00, Zeev Suraski z...@zend.com 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:12, Zeev Suraski z...@zend.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:18, Zeev Suraski z...@zend.com wrote:

 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

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 [mailto:a...@ajf.me]
 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 z...@zend.com 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/




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:23, Zeev Suraski z...@zend.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Thursday, July 24, 2014 11:21 PM
 To: Zeev Suraski
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] PHP Language Specification


 On 24 Jul 2014, at 21:18, Zeev Suraski z...@zend.com wrote:

  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).

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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Pierre Joye]

On Jul 24, 2014 10:02 PM, Zeev Suraski z...@zend.com wrote:

 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

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 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 z...@zend.com 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

Maybe there’s hope for the middle east J



*From:* Pierre Joye [mailto:pierre@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




On Jul 24, 2014 10:02 PM, Zeev Suraski z...@zend.com wrote:

 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

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

On 24/07/2014 21:28, Zeev Suraski wrote:

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ferenc Kovacs]

On Thu, Jul 24, 2014 at 10:26 PM, Andrea Faulds a...@ajf.me wrote:


 On 24 Jul 2014, at 21:23, Zeev Suraski z...@zend.com 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

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:32, Zeev Suraski z...@zend.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 24 Jul 2014, at 21:47, Zeev Suraski z...@zend.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Zeev Suraski]

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Julien Pauli]

On Tue, Jul 22, 2014 at 9:50 PM, Sara Golemon poll...@php.net 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


Nice push Sara.

Thank you.


Julien.P

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Language Specification

[Christian Stoller]

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

Re: [PHP-DEV] PHP Language Specification

[Lester Caine]

On 22/07/14 23:28, Stas Malyshev wrote:
 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Stas Malyshev]

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/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Jannik Zschiesche]

Hi,

 On 23.07.2014, at 11:22, Stas Malyshev smalys...@sugarcrm.com wrote:
 
 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Arvids Godjuks]

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.

Re: [PHP-DEV] PHP Language Specification

[Sebastian Bergmann]

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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ben Ramsey]

On Jul 23, 2014, at 1:59 PM, Rowan Collins rowan.coll...@gmail.com 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 23 Jul 2014, at 21:59, Ben Ramsey b...@benramsey.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Rowan Collins]

On 23/07/2014 13:06, Lester Caine wrote:


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 quotemarksbetweeneveryword when I copy and paste from it!


--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP Language Specification

[Sara Golemon]

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

Re: [PHP-DEV] PHP Language Specification

[rican7]

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 poll...@php.net 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

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 22 Jul 2014, at 20:50, Sara Golemon poll...@php.net 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds a...@ajf.me 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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 22 Jul 2014, at 23:32, Sara Golemon poll...@php.net 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Stas Malyshev]

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/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Tue, Jul 22, 2014 at 3:34 PM, Andrea Faulds a...@ajf.me wrote:
 On 22 Jul 2014, at 23:32, Sara Golemon poll...@php.net 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Larry Garfield]

On 7/22/14, 5:32 PM, Sara Golemon wrote:

On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds a...@ajf.me 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ben Ramsey]

On Jul 22, 2014, at 5:41 PM, Andrea Faulds a...@ajf.me wrote:

 On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds a...@ajf.me wrote:
 On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 22 Jul 2014, at 23:48, Sara Golemon poll...@php.net wrote:

 On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds a...@ajf.me wrote:
 On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Sara Golemon]

On Tue, Jul 22, 2014 at 3:56 PM, Andrea Faulds a...@ajf.me 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Andrea Faulds]

On 23 Jul 2014, at 00:01, Sara Golemon poll...@php.net 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Kris Craig]

On Tue, Jul 22, 2014 at 3:28 PM, Stas Malyshev smalys...@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/

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php