> <<huge snip>>
Stig 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. ;-)
Agree, the spec should document the current language, with notes
in special syntax where things go weird.
> 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.
Good idea, of course. Anyway, it doesn't seem Zeev&Andi WANT to write
it themselves, so this would happen anyway.
> 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.
For this, I'm switching to Zeev's mail:
>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.
I came up with it, while trying to make that documentation. As I said in my
intro-message
to the group, I planned to make the documentation quite exact, so it COULD
be rewritten
in BNF easily, but actually I was going to write it in some human readable
form: the
goal of documentation is after all be be human readable.
But while working on it, I noticed that it is quite hard to write human
readable documentation
based on the sources. You need a intermediate, that is exact, but yet well
readable for ppl
having the knowledge of parsers and languages. In fact, that IS the
specification.
So I just view on it as the link between sources and documentation for the
ordinary PHP-developper.
There are also developpers out there who really want an exact documentation,
and when the documentation
is somewhat ambigious (something you'll never be able to prevent), there is
always the spec, which is
a lot more accessible than the sources (largly uncommented... :-( )
And a second advantage of the spec is that make reflection easier: you will
notice the quirks, while with the sources,
you really have no idea what is inconsistent.
About php-clones: I agree, it is very bad to have just clones like that. But
when there IS a good specification,
there's nothing agains it IMO. But anyway, this is offtopic, Zend is okay,
and I have the trust that it will change things when possible and it doesn't
break BC. And if they don't, and only then, another implementation MIGHT
become interesting. But that's, as I cannot emphasise enough, not the goal
nor intention.
>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.
It WILL improve zend, and it is IMO the only way to get a decent and correct
documentation
of for example references. It doesn't work as documented, although it seems
logic
what is documented.
Because there is no real public audience, there is no need to make it
accessible for everyone,
it just needs to be understood by people like zend developers, and
parser-writers. That
eases the project of course a bit.
Greetz
Jeroen
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
