Loading ...
Sorry, an error occurred while loading the content.

Has JSLINT.tree changed?

Expand Messages
  • Satyam
    I don t download the latest version of JSLint every single time so I don t now in which version it might have stopped working but the script I use to detect
    Message 1 of 8 , Jun 7, 2011
    • 0 Attachment
      I don't download the latest version of JSLint every single time so I
      don't now in which version it might have stopped working but the script
      I use to detect repeated strings is no longer working. It relied in
      this part of the docs:

      // You can obtain the parse tree that JSLint constructed while parsing. The
      // latest tree is kept in JSLINT.tree. A nice stringication can be produced
      // with

      // JSON.stringify(JSLINT.tree, [
      // 'value', 'arity', 'name', 'first',
      // 'second', 'third', 'block', 'else'
      // ], 4));

      Does it still apply?

      I use the following code:

      var strs = {},
      re = /^(first|second|third|else|block|\d+)$/;
      var traverse = function (what) {
      var k,
      v = what.arity;
      if (v === 'string' || v === 'number') {
      v = what.value;
      if (v in strs) {
      strs[v] += 1;
      } else {
      strs[v] = 1;
      }
      }

      for (k in what) {
      if (what.hasOwnProperty(k)) {
      if (re.test(k)) {
      v = what[k];
      if (v) {
      traverse(v);
      }
      }
      }
      }
      };

      traverse(JSLINT.tree);


      Satyam
    • Merlin
      ... Yes, the tree is still being constructed.
      Message 2 of 8 , Jun 7, 2011
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
        >
        > I don't download the latest version of JSLint every single time so I
        > don't now in which version it might have stopped working but the script
        > I use to detect repeated strings is no longer working. It relied in
        > this part of the docs:
        >
        > // You can obtain the parse tree that JSLint constructed while parsing. The
        > // latest tree is kept in JSLINT.tree. A nice stringication can be produced
        > // with
        >
        > // JSON.stringify(JSLINT.tree, [
        > // 'value', 'arity', 'name', 'first',
        > // 'second', 'third', 'block', 'else'
        > // ], 4));
        >
        > Does it still apply?

        Yes, the tree is still being constructed.
        >
        > I use the following code:
      • Merlin
        ... Your code does not look correct to me. For example, look at the tree for the program var a = fred , b = jim ; Here is the tree: var tree = { value :
        Message 3 of 8 , Jun 7, 2011
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
          > I use the following code:

          Your code does not look correct to me.

          For example, look at the tree for the program

          var a = "fred", b = "jim";

          Here is the tree:

          var tree = {
          "value": "(begin)",
          "first": [
          {
          "value": "var",
          "arity": "statement",
          "first": [
          {
          "value": "=",
          "arity": "infix",
          "first": {
          "value": "a"
          },
          "second": {
          "value": "fred"
          }
          },
          {
          "value": "=",
          "arity": "infix",
          "first": {
          "value": "b"
          },
          "second": {
          "value": "jim"
          }
          }
          ]
          }
          ]
          };

          arity does not take values like "string' or "number"
        • Deva Satyam
          ... Then, perhaps, we might have found a bug since the tree elements with values a and b are clearly not of the same nature as those of values fred and
          Message 4 of 8 , Jun 7, 2011
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, "Merlin" <g7awz@...> wrote:
            >
            > --- In jslint_com@yahoogroups.com, Satyam <satyam@> wrote:
            > > I use the following code:
            >
            > Your code does not look correct to me.
            >
            > For example, look at the tree for the program
            >
            > var a = "fred", b = "jim";
            >
            > Here is the tree:
            >
            > var tree = {
            > "value": "(begin)",
            > "first": [
            > {
            > "value": "var",
            > "arity": "statement",
            > "first": [
            > {
            > "value": "=",
            > "arity": "infix",
            > "first": {
            > "value": "a"
            > },
            > "second": {
            > "value": "fred"
            > }
            > },
            > {
            > "value": "=",
            > "arity": "infix",
            > "first": {
            > "value": "b"
            > },
            > "second": {
            > "value": "jim"
            > }
            > }
            > ]
            > }
            > ]
            > };
            >
            > arity does not take values like "string' or "number"
            >
            Then, perhaps, we might have found a bug since the tree elements with values "a" and "b" are clearly not of the same nature as those of values "fred" and "jim", the former being identifiers the later literal values. How could you tell which is what? Is "jim" a literal or the identifier of a variable called "jim". Should I figure out that "b" must be an identifier since the "=" infix operator cannot take a literal as a "first" (left hand side) operand? It would be more handy if each element has its "arity" property stated as it did before.

            The code in my question used to work with some previous version (I recovered it from a backup), the one dated 2011-03-07. So something has, indeed, changed.
          • Joshua Bell
            ... It s not emitting a full AST in the sense that you can look at the node in the output and determine what language element it represents. That would be
            Message 5 of 8 , Jun 7, 2011
            • 0 Attachment
              On Tue, Jun 7, 2011 at 4:04 AM, Deva Satyam <satyam@...> wrote:

              >
              > Then, perhaps, we might have found a bug since the tree elements with
              > values "a" and "b" are clearly not of the same nature as those of values
              > "fred" and "jim", the former being identifiers the later literal values.
              > How could you tell which is what? Is "jim" a literal or the identifier of a
              > variable called "jim". Should I figure out that "b" must be an identifier
              > since the "=" infix operator cannot take a literal as a "first" (left hand
              > side) operand? It would be more handy if each element has its "arity"
              > property stated as it did before.
              >

              It's not emitting a full AST in the sense that you can look at the node in
              the output and determine what language element it represents. That would be
              handy, but I don't think that's a goal for JSLint at the moment. If that's
              the level of fidelity you need, you might want to take a peek at
              http://code.google.com/p/es-lab/wiki/JsonMLASTFormat

              The code in my question used to work with some previous version (I recovered
              > it from a backup), the one dated 2011-03-07. So something has, indeed,
              > changed.


              It definitely seems to have changed since I played with it last. I just ran
              this experiment:

              var a = ["a", a, /a/];

              {
              "first": [
              {
              "value": "var",
              "arity": "statement",
              "first": [
              {
              "value": "=",
              "arity": "infix",
              "first": {
              "value": "a"
              },
              "second": {
              "value": "[",
              "arity": "prefix",
              "first": [
              {
              "value": "a",
              "quote": "\""
              },
              {
              "value": "a"
              },
              {
              "value": "a"
              }
              ]
              }
              }
              ]
              }
              ]
              }

              Note that the string literal now has a quote member to disambiguate from the
              identifier (this looks to be new since your test!), but the regex literal
              doesn't have any such indicator.


              [Non-text portions of this message have been removed]
            • Merlin
              ... On JSLint Edition 2011-06-06 I have rerun your test and I see this: { value : (begin) , first : [ { value : var , arity : statement , first : [ {
              Message 6 of 8 , Jun 7, 2011
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, Joshua Bell <josh@...> wrote:

                > It definitely seems to have changed since I played with it last. I just ran
                > this experiment:
                >
                > var a = ["a", a, /a/];
                >

                On JSLint Edition 2011-06-06 I have rerun your test and I see this:

                {
                "value": "(begin)",
                "first": [
                {
                "value": "var",
                "arity": "statement",
                "first": [
                {
                "value": "=",
                "arity": "infix",
                "first": {
                "value": "a"
                },
                "second": {
                "value": "[",
                "arity": "prefix",
                "first": [
                {
                "value": "a"
                },
                {
                "value": "a"
                },
                {
                "value": "a"
                }
                ]
                }
                }
                ]
                }
                ]
                }
              • Douglas Crockford
                ... I have restored arity for literals. I had removed it because with the new type checking stuff, it had become superfluous. Please try it now. I am not
                Message 7 of 8 , Jun 7, 2011
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, Satyam <satyam@...> wrote:
                  >
                  > I don't download the latest version of JSLint every single time so I
                  > don't now in which version it might have stopped working but the script
                  > I use to detect repeated strings is no longer working. It relied in
                  > this part of the docs:
                  >
                  > // You can obtain the parse tree that JSLint constructed while parsing. The
                  > // latest tree is kept in JSLINT.tree. A nice stringication can be produced
                  > // with
                  >
                  > // JSON.stringify(JSLINT.tree, [
                  > // 'value', 'arity', 'name', 'first',
                  > // 'second', 'third', 'block', 'else'
                  > // ], 4));
                  >
                  > Does it still apply?

                  I have restored arity for literals. I had removed it because with the new type checking stuff, it had become superfluous. Please try it now.

                  I am not promising stability in the tree. JSLint's first mission is to be a code quality tool. If the quest for code quality leads me to breaking the tree, I will break the tree.
                • Deva Satyam
                  ... Works fine now, thanks. ... Being there a good reason for doing so, I don t mind, but this seemed an oversight. After all, if the tree exists at all, it
                  Message 8 of 8 , Jun 7, 2011
                  • 0 Attachment
                    --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
                    >
                    > --- In jslint_com@yahoogroups.com, Satyam <satyam@> wrote:
                    > >
                    > > I don't download the latest version of JSLint every single time so I
                    > > don't now in which version it might have stopped working but the script
                    > > I use to detect repeated strings is no longer working. It relied in
                    > > this part of the docs:
                    > >
                    > > // You can obtain the parse tree that JSLint constructed while parsing. The
                    > > // latest tree is kept in JSLINT.tree. A nice stringication can be produced
                    > > // with
                    > >
                    > > // JSON.stringify(JSLINT.tree, [
                    > > // 'value', 'arity', 'name', 'first',
                    > > // 'second', 'third', 'block', 'else'
                    > > // ], 4));
                    > >
                    > > Does it still apply?
                    >
                    > I have restored arity for literals. I had removed it because with the new type checking stuff, it had become superfluous. Please try it now.

                    Works fine now, thanks.
                    >
                    > I am not promising stability in the tree. JSLint's first mission is to be a code quality tool. If the quest for code quality leads me to breaking the tree, I will break the tree.
                    >
                    Being there a good reason for doing so, I don't mind, but this seemed an oversight. After all, if the tree exists at all, it makes sense that it should have enough information to make it worth it.
                  Your message has been successfully submitted and would be delivered to recipients shortly.