Re: [PHP-DEV] language specification project

2001-05-21 Thread 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 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]




Re: [PHP-DEV] language specification project

2001-05-21 Thread 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 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]




Re: [PHP-DEV] language specification project

2001-05-21 Thread jeroen

 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 ZeevAndi 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]




Re: [PHP-DEV] language specification project

2001-05-20 Thread 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.

snip

 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.

snip

 (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 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]




Re: [PHP-DEV] language specification project

2001-05-20 Thread 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 ZeevAndi'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.

 snip

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