Re: [PHP-DEV] language specification project

[jeroen]

> <>

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] language specification project

[Zeev Suraski]

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



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] language specification project

[Stig Sæther Bakken]

[<[EMAIL PROTECTED]>]
> Hi,
> 
> About the language specification project:
> 
> >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.
> 
> (discussed mid-november 2000)
> 
> This project seems rather dead to me. Though, I think it should be
> continued. Some work was alread been done.
> 
> I would like to try to reanimate it. I think, like Sacha I think, that a
> spec should be quite exact and precise.
> Zend was made without a proper specification, something they try to hammer
> all first-year students at my university you should NEVER do that.
> 
> It is very annoying to have to specify all quirks, I think it is most
> practical to document it the way it should be, and then note whereever it
> goes wrong.
> 
> Most of these 'where it goes wrong's are in fact quirks, that normal users
> shouldn't meet, and if they do, it works so strange, it can't be documented
> in a easy way.
> 
> (what do you think of this one:
> $a[5] = 'abc';
> $foo = &$a[5];
> 
> $b = $a; // should copy the array
> $a[5] = 'boe';
> echo $b[5]; // boe...
> 
> Array elements that have a reference are not copyd, but a reference is
> made... bah!
> )
> 
> And the target shouldn't be the user at first.
> 
> Then, IMO the next step would be to make zend comply to the specs, finally
> making version 4.1 as some people seem to want.
> And THEN you can publish the spec. With the current quirky behaviour, PHP
> won't be seen as a well and neatly specified and LOGIC language, but rather
> as some potpourri (mixup) of other languages.
> 
> But before I start, I want to know your opinions nowadays...
> And, I really need (=want) to know whether Zend WILL go comply to the new
> spec.
> 
> About what the spec exactly will be: I, and anyone who wants, just make it
> based on their own views. First of course
> the framework should be made ready, so concurrent work can be done more
> easily. I think adapting a bit to the structure of the phpdoc documentation
> isn't such a bad idea.
> 
> Regulary it is posted to phpdev, and then you can flame it, or whatever. And
> then some decission needs to be made, consensus seems hard, but hey, lets
> add the rule that if consensus isn't reached I'll decide ;)
> 
> (by the way, I came onto this trying to document the language properly, but
> that is really hard to do... if you want it to have as exact as possible)
> (BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for
> zend somewhere?)
> 
> SUMMARY:
> - spec framework made (sacha?, myself?)
> - spec made, as how it should work, so close as possible to PHP, but in case
> of quirks, just a logic behaviour.
>  (Anyone who wants. Myself included)
>   WITH notes where zend does something strange.
> - extensive discussion on phpdev
> - zend adapted
> - spec published along with new version of PHP/zend

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.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] language specification project

[jeroen]

<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Sun, 20 May 2001 [EMAIL PROTECTED] wrote:
>
> > This project seems rather dead to me. Though, I think it should be
> > continued. Some work was alread been done.
>
> Yeah, it should be very nice to have a spec, so that others can implement
> an alternative for the Zend engine (/me hides)

I didn't mention that indeed. On purpose, by the way. It needs Zeev&Andi's
help on some issues...

> > I would like to try to reanimate it. I think, like Sacha I think, that a
> > spec should be quite exact and precise.
>
> It's Sascha, not Sacha.

Sascha, I'm sorry.

> > Zend was made without a proper specification, something they try to
hammer
> > all first-year students at my university you should NEVER do that.
>
> And how do you know this? Did you ask Zeev or Andi about this? Afterall,
> Zend is a new implementation for the language that was in PHP/FI and PHP3.
> It does comply (almost) with these two versions.

If php4 WAS made after a spec, then it existed, and then Sascha wouldn't
have made
effort to make one. Simple deduction.

And referring to php/fi or php3 isn't also really referring to a spec, they
are also
just implementations, not a specification.

> > It is very annoying to have to specify all quirks, I think it is most
> > practical to document it the way it should be, and then note whereever
it
> > goes wrong.
>
> Sure, but if you want to change these 'quirks' you are gonna break lots of
> scripts that rely on those. Not an option I would think.

NO, it really isn't the purpose to break current behaviour. IMO it is very
well possible
to keep it BC.

I was thinking, that some flags could be introduced, to make it more strict,
and thus
enforce better coding. But the usual behaviour should, of course, be BC.

> 
>
> > Then, IMO the next step would be to make zend comply to the specs,
finally
> > making version 4.1 as some people seem to want.
>
> 'to make zend comply to the specs'
> Are you going to break the backwards compability?

No. Maybe in the future, but currently certainly not.

> > And THEN you can publish the spec. With the current quirky behaviour,
PHP
> > won't be seen as a well and neatly specified and LOGIC language, but
rather
> > as some potpourri (mixup) of other languages.
> >
> > But before I start, I want to know your opinions nowadays...
> > And, I really need (=want) to know whether Zend WILL go comply to the
new
> > spec.
>
> My guess is no here, BC is the word.

And what if both is possible, comply to new spec, AND BC?

>
> > (by the way, I came onto this trying to document the language properly,
but
> > that is really hard to do... if you want it to have as exact as
possible)
> > (BTW2: zend-cvs discussion? where are the archives? and is there web-cvs
for
> > zend somewhere?)
>
> Zend CVS needs no discussion on it's own, all discussion is done on
> php-dev.

But that is very cumbersome to spit :(, since all those bugs are in
between... But okay,
I know where to look.

> >
> > SUMMARY:
> > - spec framework made (sacha?, myself?)
> > - spec made, as how it should work, so close as possible to PHP, but in
case
> > of quirks, just a logic behaviour.
> >  (Anyone who wants. Myself included)
> >   WITH notes where zend does something strange.
>
> I think it would be better to document the current language as is, make
> notes about the quirks, see what can be done about those. And if there can
> be done something about these quirks without messing stuff up, change it
> in Zend (if it is possible).

I tried, for the normal documentation. But now on references, and also
errors,
I notice that it is very difficult. But I can't just write a
wish-documentation,
as it would document a version of PHP that is not yet existent...


> regards,
>
> Derick Rethans

Greetz,
Jeroen



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] language specification project

[derick]

On Sun, 20 May 2001 [EMAIL PROTECTED] wrote:

> This project seems rather dead to me. Though, I think it should be
> continued. Some work was alread been done.

Yeah, it should be very nice to have a spec, so that others can implement
an alternative for the Zend engine (/me hides)

>
> I would like to try to reanimate it. I think, like Sacha I think, that a
> spec should be quite exact and precise.

It's Sascha, not Sacha.

> Zend was made without a proper specification, something they try to hammer
> all first-year students at my university you should NEVER do that.

And how do you know this? Did you ask Zeev or Andi about this? Afterall,
Zend is a new implementation for the language that was in PHP/FI and PHP3.
It does comply (almost) with these two versions.

>
> It is very annoying to have to specify all quirks, I think it is most
> practical to document it the way it should be, and then note whereever it
> goes wrong.

Sure, but if you want to change these 'quirks' you are gonna break lots of
scripts that rely on those. Not an option I would think.



> Then, IMO the next step would be to make zend comply to the specs, finally
> making version 4.1 as some people seem to want.

'to make zend comply to the specs'
Are you going to break the backwards compability?

> And THEN you can publish the spec. With the current quirky behaviour, PHP
> won't be seen as a well and neatly specified and LOGIC language, but rather
> as some potpourri (mixup) of other languages.
>
> But before I start, I want to know your opinions nowadays...
> And, I really need (=want) to know whether Zend WILL go comply to the new
> spec.

My guess is no here, BC is the word.



> (by the way, I came onto this trying to document the language properly, but
> that is really hard to do... if you want it to have as exact as possible)
> (BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for
> zend somewhere?)

Zend CVS needs no discussion on it's own, all discussion is done on
php-dev.

>
> SUMMARY:
> - spec framework made (sacha?, myself?)
> - spec made, as how it should work, so close as possible to PHP, but in case
> of quirks, just a logic behaviour.
>  (Anyone who wants. Myself included)
>   WITH notes where zend does something strange.

I think it would be better to document the current language as is, make
notes about the quirks, see what can be done about those. And if there can
be done something about these quirks without messing stuff up, change it
in Zend (if it is possible).

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] language specification project

[jeroen]

Hi,

About the language specification project:

>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.

(discussed mid-november 2000)

This project seems rather dead to me. Though, I think it should be
continued. Some work was alread been done.

I would like to try to reanimate it. I think, like Sacha I think, that a
spec should be quite exact and precise.
Zend was made without a proper specification, something they try to hammer
all first-year students at my university you should NEVER do that.

It is very annoying to have to specify all quirks, I think it is most
practical to document it the way it should be, and then note whereever it
goes wrong.

Most of these 'where it goes wrong's are in fact quirks, that normal users
shouldn't meet, and if they do, it works so strange, it can't be documented
in a easy way.

(what do you think of this one:
$a[5] = 'abc';
$foo = &$a[5];

$b = $a; // should copy the array
$a[5] = 'boe';
echo $b[5]; // boe...

Array elements that have a reference are not copyd, but a reference is
made... bah!
)

And the target shouldn't be the user at first.

Then, IMO the next step would be to make zend comply to the specs, finally
making version 4.1 as some people seem to want.
And THEN you can publish the spec. With the current quirky behaviour, PHP
won't be seen as a well and neatly specified and LOGIC language, but rather
as some potpourri (mixup) of other languages.

But before I start, I want to know your opinions nowadays...
And, I really need (=want) to know whether Zend WILL go comply to the new
spec.

About what the spec exactly will be: I, and anyone who wants, just make it
based on their own views. First of course
the framework should be made ready, so concurrent work can be done more
easily. I think adapting a bit to the structure of the phpdoc documentation
isn't such a bad idea.

Regulary it is posted to phpdev, and then you can flame it, or whatever. And
then some decission needs to be made, consensus seems hard, but hey, lets
add the rule that if consensus isn't reached I'll decide ;)

(by the way, I came onto this trying to document the language properly, but
that is really hard to do... if you want it to have as exact as possible)
(BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for
zend somewhere?)

SUMMARY:
- spec framework made (sacha?, myself?)
- spec made, as how it should work, so close as possible to PHP, but in case
of quirks, just a logic behaviour.
 (Anyone who wants. Myself included)
  WITH notes where zend does something strange.
- extensive discussion on phpdev
- zend adapted
- spec published along with new version of PHP/zend

Greetz,
Jeroen van Wolffelaar
[EMAIL PROTECTED]





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] language specification project

[jeroen]

Hi,

About the language specification project:

>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.

(discussed mid-november 2000)

This project seems rather dead to me. Though, I think it should be
continued. Some work was alread been done.

I would like to try to reanimate it. I think, like Sacha I think, that a
spec should be quite exact and precise.
Zend was made without a proper specification, something they try to hammer
all first-year students at my university you should NEVER do that.

It is very annoying to have to specify all quirks, I think it is most
practical to document it the way it should be, and then note whereever it
goes wrong.

Most of these 'where it goes wrong's are in fact quirks, that normal users
shouldn't meet, and if they do, it works so strange, it can't be documented
in a easy way.

(what do you think of this one:
$a[5] = 'abc';
$foo = &$a[5];

$b = $a; // should copy the array
$a[5] = 'boe';
echo $b[5]; // boe...

Array elements that have a reference are not copyd, but a reference is
made... bah!
)

And the target shouldn't be the user at first.

Then, IMO the next step would be to make zend comply to the specs, finally
making version 4.1 as some people seem to want.
And THEN you can publish the spec. With the current quirky behaviour, PHP
won't be seen as a well and neatly specified and LOGIC language, but rather
as some potpourri (mixup) of other languages.

But before I start, I want to know your opinions nowadays...
And, I really need (=want) to know whether Zend WILL go comply to the new
spec.

About what the spec exactly will be: I, and anyone who wants, just make it
based on their own views. First of course
the framework should be made ready, so concurrent work can be done more
easily. I think adapting a bit to the structure of the phpdoc documentation
isn't such a bad idea.

Regulary it is posted to phpdev, and then you can flame it, or whatever. And
then some decission needs to be made, consensus seems hard, but hey, lets
add the rule that if consensus isn't reached I'll decide ;)

(by the way, I came onto this trying to document the language properly, but
that is really hard to do... if you want it to have as exact as possible)
(BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for
zend somewhere?)

SUMMARY:
- spec framework made (sacha?, myself?)
- spec made, as how it should work, so close as possible to PHP, but in case
of quirks, just a logic behaviour.
 (Anyone who wants. Myself included)
  WITH notes where zend does something strange.
- extensive discussion on phpdev
- zend adapted
- spec published along with new version of PHP/zend

Greetz,
Jeroen van Wolffelaar
[EMAIL PROTECTED]





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]