Class size and performance

[Unknown W. Brackets]

Yes, this is how mine works and definitely a good solution imho. 
Faster, more efficient, easier to debug, and cleaner.

Personally I am no fan of the auto generated parsers.  But then again, 
it depends on what you're parsing... I'm sure you'll be able to get it 
to parse ECMA cleanly and efficiently.

-[Unknown]


Daniel Lewis wrote:
> Bill Baxter Wrote:
> 
>>> I'm writing a parser too at the moment; it's a rather experimental, oddly written one though.  It [should] perform tokenization and parsing in a single O(1) pass for the ECMAScript language.
>> I call shenanigans.  Your output will be O(n), no?  Your parser can't 
>> possibly generate O(n) output in O(1) time.
>>
>> --bb
> 
> I meant for each given token; same as LL(1) or LALR(k) notation, but yes, it's a misusage of big-O.
> 
> The idea I was trying to express is this;
> 
> In most parsers, you run a giant all-you-can-eat tokenizer switch, which returns a token, and then you run some autogenerated parser switch which generates the AST.  From there, D generates an IR tree which is much flatter than the original AST, and then interprets that.
> 
> Mine runs by performing context-sensitive tokenization switches which generate the AST directly from the input stream.  It's not working for alot of different cases; there are 26 BUGS mentioned in the comments; but all of them seem solveable from within that paradigm.
> 
>