471,624 Members | 1,824 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,624 software developers and data experts.

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

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/pu...T/Ecma-262.pdf

any help/pointers gratefully received...

May 23 '06 #1
7 11891
VK

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


http://www.jslint.com

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

May 23 '06 #2
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.

May 24 '06 #3
macabstract wrote:
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
--
#define QUESTION ((bb) || !(bb))
// William Shakespeare (if he would have been a hacker ;-))
May 25 '06 #4
Thomas 'PointedEars' Lahn wrote:
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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
May 25 '06 #5
"macabstract" <ma*********@yahoo.co.uk> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...
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/pu...T/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/Produ...MSToolkit.html
--
Ira Baxter, CTO
www.semanticdesigns.com
May 25 '06 #6
Matt Kruse said the following on 5/25/2006 3:50 PM:
Thomas 'PointedEars' Lahn wrote:
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.


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 25 '06 #7
Matt Kruse wrote:
<snip>
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.
May 25 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.