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   <[email protected]>
CTO, Zend Technologies Ltd.  http://www.zend.com/