[Webkit-unassigned] [Bug 34019] Custom-written JavaScript parser

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34019





--- Comment #19 from Zoltan Herczeg <zherczeg at webkit.org>  2010-01-26 15:21:54 PST ---
(In reply to comment #18)
> (From update of attachment 47407 [details])
> I don't think there's any reason to still use cumulative "feature" flags.

I would prefer a scope flag better myself, but many nodes actually uses these
features as arguments, like BinaryOpNode (and its derived classes) has
rightHasAssignments (example: a + (b * c = d) -> AddNode rightHasAssignments
must be true), or TryNode catchHasEval, BracketAccessorNode (and similar nodes)
subscriptHasAssignments, etc. It would be really hard to decide these flags
without local features. Actually I don't know how these flags modify the
behaviour of emitByteCode, but if they are unnecessary, I could remove all of
them :)

> What you should do is have a function stack (very much pseudo code):
> struct FunctionInformation {
>     Features features;
>     Vector<VariableDeclaration> variables;
>     ... etc ...
> }
> Vector<FunctionInformation> functions;

I have exactly the same idea about function stack, except a minor tweak. The
topmost FunctionInformation is stored by the Grammar itself, and pushed to the
stack when a nested function is parsed. It is a little faster than an array
access.

> case VarDeclaration:
>     ...
>     functions.last().variables.add(theNewVariableDeclaration);
>     ...
> 
> etc
> 
> (so we lose all the various array and feature unification rules)
> 

> In terms of style rather than the current top(-n) = new Node(top(), top(-1),
> ..., top(-n)) i would prefer
> push(new Node(pop(), pop(), ...)
> 
> Which i think is much nicer.

Wow, you are right. I didn't think about it before. Actually this is possible,
since the items are not freed on the top of the stack, and the values can be
accessed before a push reuse the entry. I hope the compiler won't mess up
multiple pop()-s.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.