It could be useful to include a comment type.

Currently we have

{
  kind: 'if',
  test: <expr>,
  consequent: <expr>,
  alternate: <expr> | null
}

But most WASM documentation refers to then and else
so what about ?

{
  kind: 'if',
  test: <expr>,
  then: <expr>,
  else: <expr> | null
}

Byte-code values for:
https://github.com/drom/wast-asm
https://github.com/drom/wast-diz

could we possible use the shift AST format?
How would types be represented (i64, i32..)?
How would extending Shift to add rules for wast work?
cc @michaelficarra

so it might be a little bit more consistent if we went from identifier.id to identifier.string and change literal.raw to literal.string

related to drom/wast-parser#10

Having one kind of literals is sort of confusing.
We can split them:

• literalString --> value: String
• literali32 --> value: Number
• literalf32
• literalf64
• literali64 --> value: [ Number, Number ] (low, high) parts of number

Places to change:

• *.id ... | -> |
• export.name ... ->
• store.addr ... String -> <literal{i32,i64}>
• store.data ... String -> <literal{i32,i65,f32,f64}>
• invoke.name ... | ->
• *.failure: ... ->
• import.{modName,funcName} ... ->
• const.init ... -> <literal{i32,i64,f32,f64}>

related to: drom/wast-parser#7

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"
}

Set of structures and methods useful for other WAST tools.

so item here should be a type

{
  kind: 'param',
  items: [ <item> ]
}

would this make sense?

{
  kind: 'param',
  items: [ <type> ]
}

We have 2 type of node hierarchical properties:

1. Object -- scalar child
2. Array -- vector child

it should be possible to know type of the property value by name of the property key, like:

1. id, expr, init, test, consequent, alternate, left, right, result, module, failure, invoke -- Object
2. body, items, params, local, segment -- Array

Find all mismatches and fix.

• func.param -> func.params
• br_table.expr -> br_table.SOMETHING_ARRAY_LIKE

Tool we can use: https://github.com/okaxaki/pegjs-strip

I think name1 is the module name and name2 is the name of an exported function. What do you think about more meaningful names for the names here?