Mark S. Miller (2014-03-08T19:05:27.000Z)
domenic at domenicdenicola.com (2014-03-20T16:27:56.743Z)
Thanks for raising this. I agree you've identified a real issue. Referring to [slide #28 of Domenic's presentation](http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/28), we'd need to add an array of sourcemaps to the frozen[1] record, to parallel the raw and cooked arrays, that say where each character of the raw and/or cooked arrays come from in the source. The func, which is the template-string-parser of the embedded DSL, has no other way to recover this information. The source-map-array should probably only describe the origins of the characters in the cooked array, since the origins of the characters in the raw array can be derived from this but not vice versa. None of this would effect the use of template strings in Traceur that John describes, as he's interested in source positions in the file being translated, not source positions in the template strings within the Traceur compiler used to describe these translations. But for debugging Traceur itself, one may well be interested in the latter. There are several issues with this, none of which are show stoppers: 1. There is not yet a standard for sourcemaps. But see [Source Map Revision 3 Proposal](https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k), [Chrome Developer Tools Docs](https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps), and https://github.com/mozilla/source-map/. Would someone care to champion this for inclusion in ES7? 2. Since this can be addressed compatibly in ES7, we should note in ES6 that future editions may add more frozen data to this record, that can be feature tested for. 3. Code doesn't normally know where it came from. Adding these to template-string records will give JavaScript the power of `__FILE__` and `__LINE__`. 4. Browsers are still all over the place in how they report Error stack trace information. Even after all the renormalizing done [by SES](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#157), we still get the divergent stack traces shown at[2]. For all of these, the first stack trace comes from within a call to eval. The second from a dynamically generated script tag. 5. At [startSES.js](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#856) I'm adding the source info that eval is supposed to use, as explained at [3], where the alleged source file is http://example.com/fake1.js and http://example.com/fake2.js. (See [explicit.html](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/explicit.html#183).) However, that alleged source file name is not showing up in *any* of the browser stack traces. Am I not using [3] correctly? I would hope all of these could be addressed in ES7, including the addition of an array of source maps to the template string record. [1] A more correct expansion is: ```js var whatsThis = func( Object.freeze({ raw: Object.freeze(['', ' + ', '\\n = ', '']), cooked: Object.freeze(['', ' + ', '\n = ', '']) }), x, y, x + y ); ``` except that the record is evaluated once per evaluation of the enclosing Program (loading of the compilation unit), rather than per evaluation of the expression. This allows func to memoize template-string-parsings on the identity of the record. [2] chrome-canary-35: https://drive.google.com/file/d/0Bw0VXJKBgYPMMmVYVGtHb2tJaUk FFNightly30-0a1: https://drive.google.com/file/d/0Bw0VXJKBgYPMZFlCaDByT2YzdnM Safari702: https://drive.google.com/file/d/0Bw0VXJKBgYPMRVczXy1pOU9lcEk Opera20: https://drive.google.com/file/d/0Bw0VXJKBgYPMUjVtdWxBR0hRTUE (Unsurprisingly, essentially the same as Chrome) [3]: http://updates.html5rocks.com/2013/06/sourceMappingURL-and-sourceURL-syntax-changed http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints