Multiline Strings

Mark Miller erights at gmail.com
Sat Mar 8 11:14:58 PST 2014


On Sat, Mar 8, 2014 at 11:05 AM, Mark S. Miller <erights at google.com> wrote:

> 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.
>
>
To see these for yourself in your own browsers, visit <
http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html
>.



>
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140308/4659e035/attachment.html>


More information about the es-discuss mailing list