are empty nodes required?

[wanderer]

if you have like an empty block

{ 
  "kind":"block",
  "id":null,
  "body":[ ]
}

If the empty keys were dropped would it still be valid according to the spec? So like this

{ 
  "kind":"block"
}

[drom]

@wanderer this good question. With all AST formats that I have used, parser produces all keys. So that:

• scalar branches are Object || null
• vector branches are Array (empty or not)

you can try it here: https://astexplorer.net

{}
// -->
{ type: "BlockStatement", body: [ ] }

x = function () {}
// -->
{ type: "FunctionExpression",
  id: null, params: [ ], defaults: [ ],
  body: {    
    type: "BlockStatement",
    body: [ ]
  }
}

Do you think we should brake this tradition?

[wanderer]

Do you think we should brake this tradition?

I think it depends on priorities. So far for me when generating ast json there is less edge cases to deal with if I don't have to worry about empty keys. But if you are generating s-expression from the json ast I would assume it would be easier to have all the keys there.

[drom]

@ariya @michaelficarra Question to GURU. Should good AST format keep empty keys: id: null, body: [ ] or skip (remove) them? https://twitter.com/wavedrom/status/711318615820083200

[michaelficarra]

An empty list is not "empty" or "missing" or "null". This is an important distinction because a consumer should be able to blindly block.body.map(x => ...) without getting an error.

[wanderer]

yeah i think @michaelficarra has a good point

[drom]

@michaelficarra how about id: null vs. no id?

[michaelficarra]

What's the advantage of omitting the keys?

[wanderer]

@michaelficarra it seems easier when generating new parts of the AST when doing AST transforms. But I think the consumer concern is more important.

[drom]

how about?

1. empty Array nodes -> required
2. empty Object nodes -> optional (but parser produces them anyway)