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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140308/0df432ca/attachment.html>

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?