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
On Sat, Mar 8, 2014 at 9:30 AM, Florian Bösch <pyalot at gmail.com> wrote: > On Sat, Mar 8, 2014 at 6:10 PM, John Barton <johnjbarton at google.com>wrote: > >> You may like to take a look at how the traceur compiler ( >> https://github.com/google/traceur-compiler) works. It allows one to >> write code like >> var statement = parseStatement `${result}[${index}++] = >> ${expression};`; >> where the ${} syntax surrounds variables from the caller that are >> substituted into the string. In our case the result 'statement' is an AST >> but it could source code just as well. And source maps work fine for our >> code. Well as fine a source maps ever work ;-) >> > > That's a fine approach, and I'm not against preprocessing in any flavor if > that's your cup-o-tea. The problem rather is that one explicit usecase of > multiline strings (aka templates) is to make it easier to write DSLs. But > if you write DSLs and embedd the strings in your JS source somewhere, > you're gonna have to deal with debugging of any kind. > > For example, WebGL implementations return errors strings like these: > > ERROR: 0:1: 'foobar' : syntax error > > You can imagine that being confronted with a string like that, out of > thousands of shader code lines in your application, isn't very useful. > You'll also realize that, not all errors can actually be detected with a > validator. > > In order to make this a useful piece of error message, you'll need to > translate whatever WebGL throws back at you, to a sourceline and filename. > And unless you instrumented this beforehand with a preprocessor, you're not > gonna get it. > > So my question is this, is everybody happy with the state of affairs that > a preprocessor is the only viable way to use templates/multiline strings > for DSLs, or am I the only one who thinks that could somehow be better? > Thanks for raising this. I agree you've identified a real issue. Referring to slide #28 of Domenic's presentation at < http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/23>, 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 < https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k>, < 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 at < 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 < 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 < 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: 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-dynamic-javascript > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140308/ab629bcc/attachment-0001.html>