Re: language specification project
| From: | Zeev Suraski | Date: | Mon, 21 May 2001 09:41:22 +0000 |
| Subject: | Re: language specification project | ||
| References: | 1 2 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-56021@lists.php.net to get a copy of this message | ||
At 15:58 21/5/2001, Stig Sæther Bakken wrote:
I think the important thing is just to have the language specified and thoroughly documented, with BNF and all. Let quirks be quriks for now, a specification process should not fix them, but put them all on the radar for future fixing. There's always someone who relies on a quirk. If you mix the spec/doc and fixing processes you're in deep shit, that's something the first-year university students should learn, too. ;-) Anyway, this is a process Zeev & Andi would have to be deeply involved in, even though I think it's best to have the actual writing done by someone else, to have an extra "audit point" to come up with the questions implementors sometimes forget. On the other hand, Zeev and Andi may not want to prioritize their time on this, since a real language specification would clear the path for alternate parser implementations.Overall, I don't think I can agree with that; I'm very much in favour of the language spec effort, but instead of going the 'official ANSI-committee' approach, I was always in favour of a good documentation of what PHP is, in practice. That's what people were missing. An effort to create yet-another-language-specification is not something I consider to be interesting nor beneficial. I don't really worry about Zend Engine clones (people know enough about the PHP syntax today, they don't have to wait for me or Andi to document it, if they wanted to create such a clone). I think that having such clones would not be very beneficial for PHP to say the least, but as I said, I don't think it's related to the language spec project. The reasons Andi and I don't invest too much time in this project today are: - We simply don't have too much time, and the time we have is better spent solving real world issues. - We don't consider the project as it turned out to be all that useful in real world terms (i.e., aiming at is some formal document that theoretical language implementors would use, but effectively, nobody really will). I think that's the main reason the project ended up lingering to death - because it had very little real world use. Zeev