Its easier and cheaper to both write and interpret a pure data api.
A pure data api is going to be more easily compressible, more performant, and easier to specify (since execution state or time never enters into the picture).
It also avoids a lot of issues with your proposal, like multiple passes (do you need to run it through multiple functions? this is getting more complicated, not to mention even slower...), multiple languages (which you mentioned, but is really only an issue caused by your suggestion...)
You'll have to explain how to do it with a pure data format because I don't see how. It seems like a data format will only work for languages with a similar implementation to what the designers of the format had in mind?
As a simple example, how do you determine the type of a JavaScript object on the heap when each language implements runtime type tags differently, and each language has a different type system?
A language-specific JavaScript function running in the same heap can do whatever it likes to compute the type, including calling into the language's runtime system. Furthermore, the Chrome API I linked to doesn't even care what the type system is; all it cares is that the data can be somehow displayed in outline format.
Of course, this approach has its limitations too; it does assume that, at least at the top level of the outline, you start with a JavaScript object and there's some way to compute a runtime type from it. This doesn't work for an untagged language where we refer to objects using array indexes like with asm.js. So it's not completely general. But I think that just means the design needs improvement; I don't see how switching to a pure data format would help.
Comments
Its easier and cheaper to both write and interpret a pure data api.
A pure data api is going to be more easily compressible, more performant, and easier to specify (since execution state or time never enters into the picture).
It also avoids a lot of issues with your proposal, like multiple passes (do you need to run it through multiple functions? this is getting more complicated, not to mention even slower...), multiple languages (which you mentioned, but is really only an issue caused by your suggestion...)
You'll have to explain how to do it with a pure data format because I don't see how. It seems like a data format will only work for languages with a similar implementation to what the designers of the format had in mind?
As a simple example, how do you determine the type of a JavaScript object on the heap when each language implements runtime type tags differently, and each language has a different type system?
A language-specific JavaScript function running in the same heap can do whatever it likes to compute the type, including calling into the language's runtime system. Furthermore, the Chrome API I linked to doesn't even care what the type system is; all it cares is that the data can be somehow displayed in outline format.
Of course, this approach has its limitations too; it does assume that, at least at the top level of the outline, you start with a JavaScript object and there's some way to compute a runtime type from it. This doesn't work for an untagged language where we refer to objects using array indexes like with asm.js. So it's not completely general. But I think that just means the design needs improvement; I don't see how switching to a pure data format would help.