Re: [PHP-LANG] Approaching the First Draft [of a language spec]
[email protected] (Zeev Suraski)
| Newsgroups | php.dev,php.lang |
|---|---|
| Message-ID | <[email protected]> |
At 01:28 21/11/2000, Sascha Schumann wrote: > Hi all, > > we need a clear roadmap on how to approach the goal of having > a language specification. Here is the earlier proposal I sent > to php-dev. > > Note that this does not say anything about the format of the > final documentation. Your opinions and ideas are welcome. > > Task 1: Defining the syntax > > The syntax can be represented in the common pseudo-grammar > style, which has been used by K&R and many ANSI/ISO language > standards before. Everyone who is familiar with Yacc/Bison > will immediately recognize it. The file `Language_Notation.txt' > contains a definition and examples. > > Task 2: Defining the semantics > > This comes down to defining what meaning the various pieces of > the syntax have and what actions they cause. > > The First Draft will be based upon the language implementation > which is used by PHP 4. The draft may differ from that implementation, > if the workgroup decides so. I think that's going way off track here, and would render this project useless (I'm CCing php-dev@, because I think that even the people who don't participate in the project would have input on what they'd like to see this project do). The project, in my opinion, should be an end-user oriented project, not a vendor-spec oriented project. Thus, what we need is a descriptive specification, rather than a defining specification. Much like the ANSI C++ spec is or at least used to be useless because not a single compiler in existence implemented it (and is thus rather useless for practical purposes), defining a spec that is not backed up by the existing implementation would be useless for end users. The goal I see for this project is coming out with a document that is useful for users. Something that they could hold in their hands, and from reading it, they'd know whether something is supposed to work or not. Now, I'm sure that it's possible that during the course of the project we'll find inconsistencies in the implementation that need to be fixed, but as a guideline the spec should describe the implementation. We really don't need the kind of stuff that were with C++, with 80% conformance and 99% conformance and all that headache. Zeev -- Zeev Suraski <[email protected]> CTO, Zend Technologies Ltd. http://www.zend.com/