Proposal for encoding source-level environment information #4

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@fitzgen
Member

fitzgen commented Jul 22, 2015

Proposal for #2.

Rendered Proposal

I've tried to make this precise and detailed, perhaps at the cost of some brevity, but I was also not 100% sure how detailed and specific to be at times. I am very open to suggested changes, particularly anything that is not clear to potential implementers.

Looking forward to feedback.

@fitzgen

This comment has been minimized.

Show comment
Hide comment
@yurydelendik

This comment has been minimized.

Show comment
Hide comment
@yurydelendik

yurydelendik Aug 18, 2017

Here is a couple of thoughts related to the information expressed in encoded scopes. The first one is that scopes will be better expressed in "source location" locations. The good example of the transform, where it will be useful, is a function inlining -- the function scope is not really belong to the chain in the generated scopes where the body is inlined. (Bound locals/params need to rely on generated locations, see the thought below) It might be useful to have mapping of the generated scopes mapped to original locations to avoid guessing, when debugger is trying to resolve binding values.

The second thought is to replace BindingValue to something more like an expression, e.g. encoding folded constant, locals in an unrolled loop, or an eliminated induction variable. Notice that a binding may change its value in the same scope within generated source -- it can complicate value resolution though. Expression-like values is useful to build more "structural" value e.g. for asm.js/wasm generated from C/C++.

Here is a couple of thoughts related to the information expressed in encoded scopes. The first one is that scopes will be better expressed in "source location" locations. The good example of the transform, where it will be useful, is a function inlining -- the function scope is not really belong to the chain in the generated scopes where the body is inlined. (Bound locals/params need to rely on generated locations, see the thought below) It might be useful to have mapping of the generated scopes mapped to original locations to avoid guessing, when debugger is trying to resolve binding values.

The second thought is to replace BindingValue to something more like an expression, e.g. encoding folded constant, locals in an unrolled loop, or an eliminated induction variable. Notice that a binding may change its value in the same scope within generated source -- it can complicate value resolution though. Expression-like values is useful to build more "structural" value e.g. for asm.js/wasm generated from C/C++.

+`"mappings"` property of the source map format, and has proved valuable in
+reducing file size.
+
+The `"env"` property can be parsed with the following BNF-like grammar, where

This comment has been minimized.

@stefanpenner

stefanpenner Mar 28, 2018

Concatenation of source files, into final output files is extremely common.

One proposed aspect of sourceMap format are are sections. Although those haven't been commonly adopted, but if they were would both simplify the concatenation story and debuggers using sourceMaps story (complexity and performance) a.

Given that, I would like to recommend env also have envSections or something with a similar outcome?

@stefanpenner

stefanpenner Mar 28, 2018

Concatenation of source files, into final output files is extremely common.

One proposed aspect of sourceMap format are are sections. Although those haven't been commonly adopted, but if they were would both simplify the concatenation story and debuggers using sourceMaps story (complexity and performance) a.

Given that, I would like to recommend env also have envSections or something with a similar outcome?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment