Hi!
> The complexity of the current grammar is working against development.
I'm not sure that undertaking a task of rewriting whole grammar, with
all disruptions etc. that this is going to cause, will speed up
development a lot. But if you want to try it and show how easy it would
be with your gr
On 2012-09-04 18:36, Stas Malyshev wrote:
Hi!
The problem is that the only formal definition of the language _is_ the
parser - there's no grammar outside
zend_language_scanner.l/zend_langauge_parser.y.
I'm not sure - why exactly is it a problem here? I can understand how
having such document
Hi!
> The problem is that the only formal definition of the language _is_ the
> parser - there's no grammar outside
> zend_language_scanner.l/zend_langauge_parser.y.
I'm not sure - why exactly is it a problem here? I can understand how
having such document might be useful and interesting (not u
On 2012-09-04 04:17, Laruence wrote:
On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote:
On 03/09/12 17:03, Laruence wrote:
It is great parser(simple and fast) which make php works well for years..
No, it's not, it's overly complex. You have to define all sorts of different
expression and
On 03/09/12 17:17, Laruence wrote:
On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote:
On 03/09/12 17:03, Laruence wrote:
It is great parser(simple and fast) which make php works well for years..
No, it's not, it's overly complex. You have to define all sorts of different
expression and var
We have some RFC for parser rewrite using lemon : https://wiki.php.net/rfc/lemon
And AFAIR, adoy has a full working rewrite just as-is, the main topic
with lemon was to make the parser thread safe, not to generate an AST.
Writing a parser / compiler for using an AST is a very huge task, so
that m
On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds wrote:
> On 03/09/12 17:03, Laruence wrote:
>>
>> It is great parser(simple and fast) which make php works well for years..
>
> No, it's not, it's overly complex. You have to define all sorts of different
> expression and variable variations :(
if you
On 03/09/12 17:03, Laruence wrote:
It is great parser(simple and fast) which make php works well for years..
No, it's not, it's overly complex. You have to define all sorts of
different expression and variable variations :(
rewrite the parser for what? for more academism?
No, because current o
On Mon, Sep 3, 2012 at 11:18 PM, Andrew Faulds wrote:
> On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote:
>>
>>
>> I would like to know why? Is it a compiler related issue or just an
>> omission? Would it be interesting to fix it?
>>
> There are plenty of examples of this. One from my code:
>
> Can't
On 03/09/12 17:20, Andrew Faulds wrote:
On 03/09/12 16:20, Ivan Enderlin @ Hoa wrote:
Absolutely.
PHP has no AST? Why? For historical reasons?
I believe so. Rasmus's original parser was not exactly world-class ;)
Haha, ok ;-). Thanks. I thought it was a compiler related issue, now I
am sur
On 03/09/12 16:20, Ivan Enderlin @ Hoa wrote:
Absolutely.
PHP has no AST? Why? For historical reasons?
I believe so. Rasmus's original parser was not exactly world-class ;)
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:/
On 03/09/12 17:18, Andrew Faulds wrote:
On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote:
I would like to know why? Is it a compiler related issue or just an
omission? Would it be interesting to fix it?
There are plenty of examples of this. One from my code:
Can't do this:
self::$views[$
On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote:
I would like to know why? Is it a compiler related issue or just an
omission? Would it be interesting to fix it?
There are plenty of examples of this. One from my code:
Can't do this:
self::$views[$path]();
But I *can* do this:
$x = s
Hello,
I would like to start with an example:
a = new A();
}
public function a ( ) {
return $this->a;
}
public function f ( ) {
return $this->a::foo();
}
}
$b = new B();
var_dump($b->f());
This is not possible. We
14 matches
Mail list logo
