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

2272Re: [jslint] Re: Has JSLINT.tree changed?

Expand Messages
  • Joshua Bell
    Jun 7, 2011
      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]
    • Show all 8 messages in this topic