ES parsing tools (Re: Short Functions)

Claus Reinke claus.reinke at talk21.com
Sat May 28 01:56:15 PDT 2011


>> Mark and Tom used Ometa for  <http://code.google.com/p/es-lab/>
>> http://code.google.com/p/es-lab/ -- slo-o-o-o-wwwww.
>
> OMeta does do memoization, but it's still slow ;-)

I'm curious: what level of slow are we talking about here?

A basic memoing top-down parser for PEG-style grammars
with good representation but without further optimizations
will be too slow for interactive use (no replacement for lints
or runtime-preprocessors, never mind incrementally parsing
IDE frontends). With modern browser engines, it should be
fine for experimental use, from a few seconds for a small file
to a minute or so for a larger one (a few thousand lines).

Much of the inefficiency seems inherent in the grammar, when
viewed from a naïve top-down, backtracking, commit-to-first-
successful-branch parser. Since being close to the spec is part
of the game here, rewriting the input grammar is out, making
grammar optimizations in the parser generator important if
one wants better performance than the above. OMeta seemed
to have a good lead on that, so I expected it to be faster than
similar grammar-based top-down parsers.

If OMeta's should really be slower than similar parsers, and
the grammar-optimizing side is covered by the authors,
perhaps there is room for old-fashioned JS code optimization?
For instance, OMeta/JS is not the main line of OMeta code,
and code that is idiomatic in another language might be
less than optimal if moved to JS.

Btw, it would be nice to have an es-tools-discuss list, where
one could discuss ES implementation and tooling issues
(preferably with the engine implementers listening in).
Does such a list exist?

Claus

PS. Sometimes, I wonder whether es-discuss would profit
    from being split into es-{spec,design,tools}-discuss: more
    focus in the 'spec' part, more room in the 'design' part,
    and pragmatic realities in 'tools'.

    The 'design' part might be more inviting to all those
    research groups that have built JS semantics or analyses,
    and the 'tools' part might help to keep the variety of tool
    efforts in view. Both would invite useful input/background
    for 'spec'.
 



More information about the es-discuss mailing list