RE: [PHP-DEV] Re: [PHP-LANG] Approaching the First Draft [of a language spec]

I agree that the spec shouldn't document weird odds and ends that are either bugs or misfeatures that we decide that should be fixed as a part of the language (although it'd be a good thing to document these until they're fixed). I just think that as a general rule, describing what exists, rather than what *should* exist, is the way to go (there can be some distance between the actual implementation and the spec, due to bugs/misfeatures, but the distance should be very short). Zeev At 02:05 20/11/2000, Sterling Hughes wrote:

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. -- I agree, in part. I think however we should document the syntax as it "ought to be", ie, some of the stuff is not yet realized like what sascha was reffering to as far as the zend-cvs discussion (which I didn't really follow too well). Or, obviously, bugs should not be at all considered in the specification itself. -Sterling

-- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/