Object representation should be primary

At https://mail.mozilla.org/pipermail/es-discuss/2016-February/045493.html I write:

Unless the object representation is primary, we will need to agree on comprehensive escaping rules, and corresponding parsing rules, so that these stack strings can be unambiguously scraped even when file names and function names contain parens, slashes, angle brackets, at-signs, spaces, etc. Therefore, we should focus on the object representation first.

Your object representation above looks like a good start. It is similar to the extended Causeway stack format I mentioned earlier

    stacktrace ::= {calls: [frame*]};
    frame ::= {name: functionName,
               source: source,
               span: [[startLine,startCol?],[endLine,endCol?]?]};
    functionName ::= STRING;
    startLine, startCol, endLine, endCol ::= INTEGER
    source ::= STRING | frame;

with the following differences:

You added an isTail. This is probably a good thing. I'd like to understand better what you have in mind.
Rather than have a single span property with a nested array of numbers as value, you define separate line and column property names. As long as we represent all that we need unambiguously, I'm indifferent to minor surface syntax differences.
Causeway's format has room for both start(line,col) and end(line,col). The format must include room for this, and I would hope any future standard would mandate that they be included. Such span information makes a huge usability improvement in reporting diagnostics.
The extended Causeway source field could be either a string as with your's, or a nested frame. This is necessary to preserve the information currently provided on both FF and Chrome of the nested positions in a single frame, when a call happens at position X in an eval string that was evaled by an eval call at position Y. (That is what the "extended" means. Causeway originally only has strings as the value of their source property.)

The proposed[1] API is:

System.getStack(err) -> stack-representation
Reflect.stackString(stack-representation) -> stack-string
System.getStackString(err) -> stack-string

where getStackString is just the obvious composition of getStack and stackString.

[1] Hopefully https://github.com/tc39/ecma262/issues/395 will resolve in time that none of these need to be rooted in globals.

At https://mail.mozilla.org/pipermail/es-discuss/2016-February/045494.html I wrote:

isTail will be set when the frame indicates a frame created by tail call instead of normal function call. Caller's frame is already removed so we need some indication for that to help debugging.
For span, I put only one pair of line/column there as it is the common implementation, but I agree that a starting position and a ending one is useful.
For source, nested frame could be useful but it is not implemented by all implementations, and in fact we need an extra field to distinguish eval and new Function.
By reference to function, I mean that shall we be able to retrieve the function object from the frame?
I wonder if putting special cases in (), such as (native) will cause any problem. No one will have a file called "(native)" in reality, isn't it?

nbdd0121 / es-error-stack

Object representation should be primary #1