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

Discussion in 'Javascript' started by macabstract, May 23, 2006.

  1. macabstract

    macabstract Guest

    macabstract, May 23, 2006
    #1
    1. Advertising

  2. macabstract

    VK Guest

    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?
    VK, May 23, 2006
    #2
    1. Advertising

  3. macabstract

    macabstract Guest

    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.
    macabstract, May 24, 2006
    #3
  4. 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 ;-))
    Thomas 'PointedEars' Lahn, May 25, 2006
    #4
  5. macabstract

    Matt Kruse Guest

    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
    Matt Kruse, May 25, 2006
    #5
  6. macabstract

    Ira Baxter Guest

    "macabstract" <> wrote in message
    news:...
    > 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


    --
    Ira Baxter, CTO
    www.semanticdesigns.com
    Ira Baxter, May 25, 2006
    #6
  7. macabstract

    Randy Webb Guest

    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/
    Randy Webb, May 25, 2006
    #7
  8. 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.
    Richard Cornford, May 25, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Moonlit

    Best lex/yacc for C++?

    Moonlit, Oct 8, 2003, in forum: C++
    Replies:
    18
    Views:
    1,533
    Moonlit
    Oct 14, 2003
  2. Arthur T. Murray

    Re: Parsing English with lex and yacc

    Arthur T. Murray, Jan 23, 2004, in forum: C++
    Replies:
    5
    Views:
    1,308
    Amnon Meyers
    Jan 26, 2004
  3. Alvaro Puente

    YACC-LEX parsing overflow

    Alvaro Puente, Jul 10, 2003, in forum: C Programming
    Replies:
    1
    Views:
    382
    Chris Dollin
    Jul 10, 2003
  4. cylin
    Replies:
    1
    Views:
    422
    Ben Pfaff
    Jan 7, 2004
  5. Gvs

    lex and yacc

    Gvs, May 11, 2005, in forum: C Programming
    Replies:
    3
    Views:
    475
    T.M. Sommers
    May 12, 2005
Loading...

Share This Page