[Webkit-unassigned] [Bug 34019] custom-written parser

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Oliver Hunt <oliver at apple.com>  2010-01-22 15:05:31 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > I'm unsure why the syntax checker is separate from the parser.  Syntax checking
> > is basically answering the question "can i parse this".
> 
> The grammar do both syntax checking and generating nodes. Syntax checker only
> checks syntax, and used only for skipping nested function bodies. That is what
> I tried to explain. They have lot in common, but they have differences as well.

Basically the parser should be set up with a flag along the lines of
parse(int maxFunctionASTDepth) {
...
}

then the various functions to create nodes should basically be
if (currentFunctionDepth < maxFunctionDepth)
    newNode = new ...;

Having the ability to dynamically vary how deep we generate the tree will be
beneficial for certain real world cases.

> 
> > There are semantic checks that we will want to do while parsing:
> >    the various "features" we track
> >    variable and function accumulation
> >    partial AST generation
> 
> That is what my grammar do :) It is "binary compatible" with the bison parser.
> The only thing which is not tracked is the "arguments feature" because I don't
> really understand its purpose yet :(

Whether a function ever references a variable with the name "arguments" -- we
need to know whether the arguments object may have been used.

> 
> > New things we _must_ be able to do in the new parser:
> >    strict mode identification needs to be done during the parse stage and
> > alters the state of the parser to reject constructs that lax mode would allow,
> > and produces parse time errors instead).  For efficiency reasons this basically
> > forces us into a recursive-descent parser :-/
> 
> I saw the new ECMA standard, and I think I can hanle the strict mode
> restrictions, at least those which I saw (local identifiers cannot be used
> before a var declaration seems a more complex one, since you have to store all
> the primary identifiers during parsing). I checked wikipedia, and turned out my
> parser is a predictive parser (uses a stack, but never backtracks). The
> predictive parser belongs to the family of recursive descent parsers.

Everything should be trivial i think, the parser is gnarly enough to make me
sad though.

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