JavaScript parser in lex+yacc or jflex+byacc/j

[macabstract]

does anyone know of a "reasonably practical" yacc-type parser for
JavaScript?

in the absence of one, i will endevour to write my own starting from
the BNF specification:

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

any help/pointers gratefully received...

 

[VK]

does anyone know of a "reasonably practical" yacc-type parser for
JavaScript?

http://www.jslint.com

.... unless what does "reasonably practical" mean to you?

 

[macabstract]

i need a lexer/parser in a high-level parsing language such as lex/yacc
rather than a coded-from-scratch one in C/Java/JS (as is the case with
jslint).

my motivation is to write a JavaScript/AJAX obfuscation utility to
mangle variable names between JavaScript and the server-side language
(typically Java/C#).

by "reasonably practical" (apologies for my vagueness), i meant that
the grammar used should be consistent with JavaScript used in popular
browsers such as Mozilla and IE.

 

[Thomas 'PointedEars' Lahn]

my motivation is to write a JavaScript/AJAX obfuscation utility to
mangle variable names between JavaScript and the server-side language
(typically Java/C#).

What should this be good for?

by "reasonably practical" (apologies for my vagueness), i meant that
the grammar used should be consistent with JavaScript used in popular
browsers such as Mozilla and IE.

Unlike Mozilla and other Gecko-based UAs, IE supports JScript, not
JavaScript. Furthermore, JavaScript and JScript are ECMAScript
implementations that extend the specified language; probably you
will have to take several peculiarities of those languages into
account.


PointedEars

 

[Matt Kruse]

Unlike Mozilla and other Gecko-based UAs, IE supports JScript, not
JavaScript. Furthermore, JavaScript and JScript are ECMAScript
implementations that extend the specified language;

When the implementations were created before the standard existed, is it
really accurate to say they are implementations of the standard? That's
putting the cart before the horse.

Shouldn't you say that ECMAScript is a proposed standard which attempts to
unify, extend, and standardize Javascript and JScript into a language
definition that encapsulates most of the functionality of each and provides
a starting point for future new implementations and changes to Javascript
and JScript?

Repeatedly parroting that "Javascript and JScript are ECMAScript
implementations" is a bit misleading, IMO.

 

[Ira Baxter]

does anyone know of a "reasonably practical" yacc-type parser for
JavaScript?

in the absence of one, i will endevour to write my own starting from
the BNF specification:

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

any help/pointers gratefully received...

The DMS Software Reengineering Toolkit has excellent parsers for
Javascript. It is frankly a lot of work to get the details for the
various
Javascript dialects right. DMS also provides considerable
support for custom analysis or transformation on the parsed
code.

We use DMS + these grammars to provide JavaScript source formatting tools,
obfuscation tools (which some folks in this group just can't
get over) and other tools that require deep, detailed access to the
JavaScript
(and/or the HTML page in which it is often embedded),
such as clone detection. An example next tool on which we are
working would be test coverage for JavaScript;
we've already delivered test coverage tools for half a dozen
other languages using DMS.

See http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

 

[Randy Webb]

Matt Kruse said the following on 5/25/2006 3:50 PM:

When the implementations were created before the standard existed, is it
really accurate to say they are implementations of the standard? That's
putting the cart before the horse.

Thats putting the cart before the wheel before the horse.

Shouldn't you say that ECMAScript is a proposed standard which attempts to
unify, extend, and standardize Javascript and JScript into a language
definition that encapsulates most of the functionality of each and provides
a starting point for future new implementations and changes to Javascript
and JScript?

But then they all repeat the "But the website says it is an ECMAScript
implementation".

Repeatedly parroting that "Javascript and JScript are ECMAScript
implementations" is a bit misleading, IMO.

It is very misleading.

 

[Richard Cornford]

Matt Kruse wrote:

When the implementations were created before the
standard existed, is it really accurate to say they
are implementations of the standard? That's putting
the cart before the horse.

<snip>

When pre-existing JavaScript(tm) and JScript implementations have
changed in a way that brings them into line with ECMA 262 editions, and
then been claimed by their authors to be ECMAScript implementations,
shoudn't we accept that that is what they are.

The significant differences between JavaScript(tm) 1.2 and 1.3, where
the latter brought JavaScript(tm) into line with ECMA 262, 2nd Ed. being
an obvious example. The introduction of previously absent
properties/methods into JScript 5.6 to bring it into line with ECMA 262,
3rd Ed. being another.

Richard.