From: Thomas 'PointedEars' Lahn on
Michael Haufe ("TNO") wrote:

> Thomas 'PointedEars' Lahn wrote:
>> The syntax you have used to date apparently makes use of a bug in
>> Gecko's ECMAScript for XML (E4X, ECMA-357) implementation. V8 breaks
>> on this syntax because syntactically valid ECMAScript for XML is
>> expected, and `<>' is not well-formed XML:
>
> "<>"..."</>" is an XMLList initializer described under ECMA-357
> section 11.1.5, so I don't see how its a bug.

Thank you, that is correct. Obviously now, E4X is more complex than
I/we thought. The relevant productions here are:

| PrimaryExpression :
| PropertyIdentifier
| XMLInitialiser
| XMLListInitialiser
|
| [...]
| XMLListInitialiser :
| < > XMLElementContent_opt </ >
|
| [...]
| XMLElementContent :
| XMLMarkup XMLElementContent_opt
| XMLText XMLElementContent_opt
| XMLElement XMLElementContent_opt
| { Expression } XMLElementContent_opt
|
| [...]
| XMLMarkup ::
| XMLComment
| XMLCDATA
| XMLPI
|
| [...]
| XMLCDATA ::
| <![CDATA[ XMLCDATACharacters_opt ]]>
|
| XMLCDATACharacters ::
| SourceCharacters but no embedded sequence ]]>

And

| 10.1.2 ToString Applied to the XMLListType
|
| [...]
| Note that the result of calling ToString on a list of size one is
| identical to the result of calling ToString on the single item
| contained in the XMLList. This treatment intentionally blurs the
| distinction between a single XML object and an XMLList containing
| only one value to simplify the programmer's task. It allows E4X
| programmers to access the value of an XMLList containing only a
| single primitive value in much the same way they access object
| properties.

makes sure that if E4X were supported, Matt's approach would work.
In fact, it should even be possible to omit the parentheses (WFM
in Gecko/TraceMonkey 1.9.1.6).


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: "Michael Haufe ("TNO")" on
On Feb 2, 8:37 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> Thank you, that is correct.  Obviously now, E4X is more complex than
> I/we thought.

<offtopic>
Of course, E4X in its present state is considered a mistake by many
in its current form. I wouldn't be surprised if there are no other
implementations in the future.

More info:
https://bugzilla.mozilla.org/show_bug.cgi?id=509705#c8
http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/6566b430328bc3ef/9f9005c6525464c6
</offtopic>
From: Thomas 'PointedEars' Lahn on
Michael Haufe ("TNO") wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Thank you, that is correct. Obviously now, E4X is more complex than
>> I/we thought.
>
> <offtopic>

It's not.

> Of course, E4X in its present state is considered a mistake by many
> in its current form.

By whom, and do their voices count?

> I wouldn't be surprised if there are no other
> implementations in the future.

I would:

> More info:
> https://bugzilla.mozilla.org/show_bug.cgi?id=509705#c8
> http://groups.google.com/group/mozilla.dev.tech.js-
engine/browse_thread/thread/6566b430328bc3ef/9f9005c6525464c6

That's *one* and the same voice (Brendan Eich) in both discussions. Some
with some weight no doubt, but none that provides indication that other
vendors would not be implementing what is already implemented elsewhere (in
JavaScript and ActionScript). In fact, the more it is used in Mozilla, and
cannot be used elsewhere (as in this Greasemonkey example), the greater the
pressure for other vendors to do something about that.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on
Stefan Weiss wrote:

> Matt Kruse wrote:
>> In my Greasemonkey code written specifically for Firefox, I use this
>> "heredoc" syntax a lot:
>>
>> var myBigBlob = (<><![CDATA[
>>
>> ... insert a bunch of free-form text here ...
>>
>> ]]></>).toString();
>>
>> Now that Chrome offers built-in Greasemonkey support, I'd like to
>> support it as well, but it breaks on this syntax.
>>
>> Does anyone know of a better method that will work in both browsers?
>
> Sorry, I don't. I've always wondered why multi-line string literals
> aren't possible in JavaScript. AFAICS, there's nothing ambiguous about
> this syntax:
>
> var heredoc = "I am a multi-line
> string; I end when the tokenizer
> sees a double quote";

Nothing ambiguous? To begin with, should that be the equivalent of

var heredoc = "I am a multi-line string; I end when the tokenizer sees a
double quote";

or

var heredoc = "I am a multi-linestring; I end when the tokenizersees a
double quote";

? Besides, you forgot to consider `\"' in your description.

> This is standard practice in many other programming languages.

All other programming languages that I know to support this except PHP
require special syntax there. So which "many other programming languages"
are you referring to?

> Maybe ES4 had something like this in the queue, but with ES5 geared
> towards backwards compatibility, we probably won't see it for a long
> time.

You are not making sense, see below.

> The two usual workarounds are
>
> var str = "I wish\n"
> + "I was\n"
> + "a multi-line string";

Joining an Array of strings on newlines appears to be easier to maintain:

var str = [
"I wish",
"I was",
"a multi-line string"
].join("\n");

> and
>
> var str = "I am the closest thing\
> to multi-line strings that we can get\
> with JavaScript";

That is not equivalent, of course, as the leading spaces are part of the
string value.

> I don't know how well supported the second version is.

I have a fair idea. My tests indicate that this feature first specified
in ECMAScript Edition 5 is supported since JavaScript 1.8.1 (at least),
JScript 5.1.5010, V8 1.3 (at least), JavaScriptCore 525.13 (at least),
Opera ECMAScript 10.10 (not before), and KJS 4.3.2 (at least).

The next release of the ECMAScript Support Matrix will feature that test
case.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: John G Harris on
On Wed, 3 Feb 2010 at 03:03:45, in comp.lang.javascript, Stefan Weiss
wrote:

<snip>
>I've always wondered why multi-line string literals
>aren't possible in JavaScript. AFAICS, there's nothing ambiguous about
>this syntax:
>
> var heredoc = "I am a multi-line
> string; I end when the tokenizer
> sees a double quote";
>
>This is standard practice in many other programming languages.
<snip>

In C++ you would write

var heredoc = "I am a multi-line "
"string; I end when the tokenizer "
"sees a double quote";

or

var heredoc = "I am a multi-line\n"
"string; I end when the tokenizer\n"
"sees a double quote";

Note the double quotes at both ends of the string parts. This way, you
know exactly which whitespace chars belong to the string parts and which
are just there for layout.

John
--
John Harris