You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do you as maintainers of the php-src project want pull requests, etc. to get this spec slowly but surely up to date?
Or would it make sense to archive this project so that it is obvious that nothing is going to be changed here.
The responses in my issue #265 indicate that this repo is not active anymore.
It's always been the official policy that php-src is the authoritative source and php-langspec describes what the source does. Except it rarely gets updated - just look at the commit history: I count 3 meaningful edits in the last 2 years.
That's a backwards situation from how specifications normally work. So +1 that, unless something changes and PHP does a much better job at remembering to keep this repo up to date (and asking the community to pick up the slack isn't fair), leaving it around will do more harm than good.
I agree. Keeping this repository open is misleading, and as Damian said, php-src is authoritative source of truth. In terms of grammar, zend_language_parser.y is really quite readable and easy to understand.
For a while I had a pipeline running that would run the tests of this repo against php-src master whenever there were changes there and that helped keep it up to date. We could do something similar again if we want to revive this repo.
Otherwise, and considering that maybe the drift is already too large and that there is little interest, the best option may be to archive it.
IMO, the reason this is not kept up to date is that it's additional effort with little benefit, rather than (just) people forgetting about it. I don't want to undermine the effort that went to it, so maybe @smalyshev can chime in, especially to elaborate on its original purpose and whether that is still relevant today.
I was of the impression that we set this up because the Facebook people wanted a shared spec? At some point we spoke about requiring updates here with new syntax RFCs, but I don't think we ever did that...
Now HHVM no longer cares either, and haven't been for a while. As this hasn't been maintained for ages, I also think we should mothball this.
In my opinion, it would be great to have a formal language specification (it's not only about the syntax, but also semantics, and even a set of built-in functions). The problem is, however, that it's hard for us to maintain the implementation, the documentation (PHP manual), and a formal language specification, given that PHP is still evolving.
Particularly maintaining the conformity test suite is extremly hard (originally, there were pure PHP tests; only a while later they had been converted to PHPT, what already might be an issue for other implementations, because they would not only need to conform to the engine, but also to PHPT). And actually, it is impossible to maintain a conformity test suite, unless this would be versioned (a "living standard" is an oxymoron), so even more work.
In hindsight I think it was a bad idea to put this under the PHP umbrella. It should have been maintained by an independent group, but in that case PHP would likely have developed independently, because it had even been more work to get this group to accept changes from PHP to incorporate in a new version of the standard.
Reacted by Craig Duncan-Courcey, Ilija Tovilo and Gina Peter Banyard
Activity
cmb69 commentedon Oct 22, 2024
In my opinion, this repo should better be archived. I don't think it has any practical purpose nowadays. PHP evolves indenpendently from Hack/HHVM.
damianwadley commentedon Oct 22, 2024
It's always been the official policy that php-src is the authoritative source and php-langspec describes what the source does. Except it rarely gets updated - just look at the commit history: I count 3 meaningful edits in the last 2 years.
That's a backwards situation from how specifications normally work. So +1 that, unless something changes and PHP does a much better job at remembering to keep this repo up to date (and asking the community to pick up the slack isn't fair), leaving it around will do more harm than good.
iluuu1994 commentedon Oct 23, 2024
I agree. Keeping this repository open is misleading, and as Damian said, php-src is authoritative source of truth. In terms of grammar, zend_language_parser.y is really quite readable and easy to understand.
pmmaga commentedon Oct 23, 2024
For a while I had a pipeline running that would run the tests of this repo against php-src master whenever there were changes there and that helped keep it up to date. We could do something similar again if we want to revive this repo.
Otherwise, and considering that maybe the drift is already too large and that there is little interest, the best option may be to archive it.
iluuu1994 commentedon Oct 23, 2024
IMO, the reason this is not kept up to date is that it's additional effort with little benefit, rather than (just) people forgetting about it. I don't want to undermine the effort that went to it, so maybe @smalyshev can chime in, especially to elaborate on its original purpose and whether that is still relevant today.
php-pulls commentedon Oct 23, 2024
derickr commentedon Oct 23, 2024
I still don't understand why it sometimes uses @php-pulls when I reply by email :-/
cmb69 commentedon Oct 23, 2024
See https://externals.io/message/75886 for some background.
In my opinion, it would be great to have a formal language specification (it's not only about the syntax, but also semantics, and even a set of built-in functions). The problem is, however, that it's hard for us to maintain the implementation, the documentation (PHP manual), and a formal language specification, given that PHP is still evolving.
Particularly maintaining the conformity test suite is extremly hard (originally, there were pure PHP tests; only a while later they had been converted to PHPT, what already might be an issue for other implementations, because they would not only need to conform to the engine, but also to PHPT). And actually, it is impossible to maintain a conformity test suite, unless this would be versioned (a "living standard" is an oxymoron), so even more work.
In hindsight I think it was a bad idea to put this under the PHP umbrella. It should have been maintained by an independent group, but in that case PHP would likely have developed independently, because it had even been more work to get this group to accept changes from PHP to incorporate in a new version of the standard.