Discuss
  • Forwards-compatible syntax proposal

Forwards-compatible syntax proposal

# Ian Hickson (17 years ago)

One of the problems with ES4 relative to ES3 is that the new syntax means that a script using ES4 features doesn't work in ES3 compilers.

There's not much we can do in the ES3-ES4 language migration about this. But we can prevent this problem from existing again in ES5 and up.

I propose that ES4 clients, when they hit a syntax error, back up to the start of the current block, and then look for the end of the block, which is the "}" corresponding to the last token in this grammar:

block = "{" tokens* "}" tokens = block | string | comment | regexp | other string = single-quote [ no-backslash | escape ]* [ single-quote | end of line ] string = double-quote [ no-backslash | escape ]* [ double-quote | end of line ] string = (triple-quoted string) no-backslash = anything but "" escape = "" followed by anything comment = "/" ... "/" comment = "//" ... end of line comment = "<!--" ... end of line regexp = "/" [ no-backslash | escape ]* [ "/" | end of line ] other = anything else

...and then compile the whole block to one "throw SyntaxError" statement.

I may have missed some things we should include, and the grammar above may be too simple and may have to have changes made, but hopefully it conveys the basic idea.

Comments?

# Lars Hansen (17 years ago)

From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Ian Hickson Sent: 8. mai 2008 20:18 To: es4-discuss at mozilla.org Subject: Forwards-compatible syntax proposal

One of the problems with ES4 relative to ES3 is that the new syntax means that a script using ES4 features doesn't work in ES3 compilers.

To be precise, what you're saying is that there are ES4 source fragments that can't be parsed by ES3 compilers.

I have various reactions to this statement, but among the top contenders are :

  • rejecting syntactically invalid scripts is a feature, not a bug

  • a quiet fallback is going to make web developers' lives even worse, having to content not just with incompatible implementations of a known language but implementations that may censor content in scripts

    (As syntax evolves across multiple language versions, different parts of the language are censored by this mechanism, so an ES5 program running on an ES3 implementation and an ES4 implementation would have two different behaviors.)

  • this looks like compatibility handling that applies to a particular environment, and like handling <!-- syntax it seems like something browser vendors might try to agree on outside the forum of ECMAScript

Another reaction is that there are ES4 source fragments that /can/ be parsed by ES3 compilers, but whose meaning will silently be something completely different in the two versions of the language. Here are some:

// a generator expression in ES4, a loop calling a function // in ES3

function f(x) { for ( i=0 ; i < 10 ; i++ ) yield (f(), i) }

// (artificial) three statements in ES3, two in ES4

x = this function f(x) { x++ }

Finally, I'm worried that accepting your proposal will prevent a language processor from reporting syntax errors. This seems like it has important usability problems.

Summing up, the effect of your proposal is that some (many? most?) new scripts are rejected late rather than early, and some new scripts just compute different results in old implementations. My gut feeling is that both are bad ideas, but in any case still that this is a case for a web standards group to deal with.

I know, those are not technical arguments. As an exercise we should apply your proposal to the ES3-ES4 migration to see how it would have applied there. What we're looking for are plausible programs that are not valid ES3 but for which a valid ES3 implementation using your fallback would terminate normally with an erroneous answer.

All programs using exceptions for control flow are candidates:

function trampolineLoop(f) { for (;;) try { return f(); } catch (x) { f = x } }

function f1() { throw function () { return f2(...a) } } // splat is ES4 syntax

trampolineLoop(f1)

This program loops forever if the ES4 body is replaced by code that throws a syntax error.

There's more to be said here, presumably, and despite the fact that I'm sympathetic to the notion of reporting errors as late as possible in some deployment situations, I'm skeptical as to whether this kind of a fallback is right for a computational language like ES, as opposed to a declarative -- and non-looping -- language like HTML, and I'm fairly sure this kind of fallback does not really belong in the ES spec proper.

# Kris Zyp (17 years ago)

FWIW, using a similar feature in Eclipse's Java compiler (ability to compile/execute code that has syntax errors) has been a very positive experience for me. I realize this is different than the goal of forward compatibility, but being able to prototype code without eliminating every syntax errors has been a big time saver for me in development. Also, applying the scope of rejection of syntactic problem to a script file seem a little bit arbitrary. If you concatenate multiple files and one has a syntax error then the concatenation changes the behavior. None of these are real technical arguments, but if it comes to preference, defining the scope of rejection to a well-defined code block seems attractive to me. This also seems easier to to make it easier to take advantage of ES4 features from code that must run in ES3 environments, rather than using an eval. In the past I have written code that uses JS1.5 conditional catches when available by doing an eval when the correct environment is detected. An eval is necessary because otherwise the entire script would be rejected by other browsers if a conditional catch is present. However, even with my example, the Eclipse compiling feature was not in the actual Java language specification (at least I don't think Java defines any such behavior, I think that is an Eclipse thing). Perhaps this is something that would be outside ES4, but would be nice for browsers to implement. I like it though. Kris

----- Original Message ---

# Ian Hickson (17 years ago)

On Mon, 12 May 2008, Lars Hansen wrote:

One of the problems with ES4 relative to ES3 is that the new syntax means that a script using ES4 features doesn't work in ES3 compilers.

To be precise, what you're saying is that there are ES4 source fragments that can't be parsed by ES3 compilers.

I have various reactions to this statement, but among the top contenders are :

  • rejecting syntactically invalid scripts is a feature, not a bug

That's what the XML proponents argued, but I think we can firmly say that that is a failed experiment, at least on the Web. :-) CSS and HTML already have the feature that they are resilient to new syntax, I think the forward compatibility this offers is far more valuable than the "draconian" error handling in JS today.

  • a quiet fallback is going to make web developers' lives even worse, having to content not just with incompatible implementations of a known language but implementations that may censor content in scripts

Certainly I agree that developer tools should report these invalid blocks proactively; I'm not suggesting that the failure mode should be any more silent than today's failure mode. I'm only suggesting that the failure mode be reduced in scope from the program-level (<script> block) to the

lexical level ({} block).

(As syntax evolves across multiple language versions, different
parts of the language are censored by this mechanism, so
an ES5 program running on an ES3 implementation and an ES4
implementation would have two different behaviors.)

Right, that's the idea. :-)

  • this looks like compatibility handling that applies to a particular environment, and like handling <!-- syntax it seems like something browser vendors might try to agree on outside the forum of ECMAScript

I'm not sure I follow what you mean here.

Another reaction is that there are ES4 source fragments that /can/ be parsed by ES3 compilers, but whose meaning will silently be something completely different in the two versions of the language. Here are some:

// a generator expression in ES4, a loop calling a function // in ES3

function f(x) { for ( i=0 ; i < 10 ; i++ ) yield (f(), i) }

// (artificial) three statements in ES3, two in ES4

x = this function f(x) { x++ }

I think this is very dangerous, and unwise, in the context of the Web. I strongly believe that if we want to have success in expanding the Web platform, backwards-compatibility is critical. But that's another issue.

Finally, I'm worried that accepting your proposal will prevent a language processor from reporting syntax errors. This seems like it has important usability problems.

I agree that we should be careful to define this in a way that doesn't preculde lanugage processors from actively reporting all syntax errors, even if the resulting code still compiles in some sense.

All programs using exceptions for control flow are candidates:

function trampolineLoop(f) { for (;;) try { return f(); } catch (x) { f = x } }

function f1() { throw function () { return f2(...a) } } // splat is ES4 syntax

trampolineLoop(f1)

This program loops forever if the ES4 body is replaced by code that throws a syntax error.

How would this be different from the same program in an out of memory situation where calling f1 results in an OOM exception?

(As an aside -- I've no idea what the above program is supposed to do. Maybe the new syntax in this example needs some work to make it more intuitive, I'm not sure.)

# zwetan (17 years ago)

On Fri, May 9, 2008 at 4:18 AM, Ian Hickson <ian at hixie.ch> wrote:

One of the problems with ES4 relative to ES3 is that the new syntax means that a script using ES4 features doesn't work in ES3 compilers.

There's not much we can do in the ES3-ES4 language migration about this. But we can prevent this problem from existing again in ES5 and up.

[...]

I may have missed some things we should include, and the grammar above may be too simple and may have to have changes made, but hopefully it conveys the basic idea.

Comments?

what about proposals:versioning and discussion:versioning

?

if I read those documents well ES1-4 support backward-compatibility

and later for ES5 etc. we could either use application/ecmascript;version=5

or the global MAX_ECMASCRIPT_VERSION

or the pragma use edition 5

re-reading what you're asking

But we can prevent this problem from existing again in ES5 and up.

do you mean you wish an ES5 script to be able to run in an ES4 interpreter/compiler ?

I don' think that 1) it's possible and 2) it's wishable

if you got application/ecmascript;version=4 and want to run a ES5 script, you fall in the same situation as ES3.1 vs ES4

see proposals:versioning "Modifications of Global Bindings

Changing global object bindings is incompatible with ES4.

If ES3 or ES3.1 code tries to overwrite these bindings before any ES4 code has executed in the current document, these bindings are changed, but further ES4 scripts will not execute in that document.

If ES3 or ES3.1 code tries to overwrite these bindings after any ES4 code has executed in the current document, the bindings will be treated as readonly and the attempt to change them will fail silently."

so ES3.1 and ES4 are a special situation, but in the context of having an ES5 script running inside an ES4 interpreter and having errors failing silently that could be really a hell to debug.

# Waldemar Horwat (17 years ago)

This wouldn't work. Without syntactically distinguishing a / that is a division from a / that starts a regexp, there is no way to find the end of the block. To make this distinction you need to be able to parse the contents of the block without errors.

To complicate matters further, various language extension proposals, ranging from ES3.1 to various ES4 extensions, muck with the regexp syntax.

Waldemar
# Mike Samuel (17 years ago)

2008/5/13 <es4-discuss-request at mozilla.org>:

what about proposals:versioning and discussion:versioning

?

if I read those documents well ES1-4 support backward-compatibility

and later for ES5 etc. we could either use application/ecmascript;version=5

or the global MAX_ECMASCRIPT_VERSION

or the pragma use edition 5

On developer tools and mime-types, subversion will treat application/ecmascript as binary.

subversion.tigris.org/faq.html#binary-files

Subversion treats the following files as text:

  • Files with no svn:mime-type
  • Files with a svn:mime-type starting "text/"
  • Files with a svn:mime-type equal to "image/x-xbitmap"
  • Files with a svn:mime-type equal to "image/x-xpixmap"

All other files are treated as binary, meaning that Subversion will:

  • Not attempt to automatically merge received changes with local changes during svn update or svn merge
  • Not show the differences as part of svn diff
  • Not show line-by-line attribution for svn blame
# zwetan (17 years ago)

2008/5/13 Mike Samuel <mikesamuel at gmail.com>:

2008/5/13 <es4-discuss-request at mozilla.org>:

what about proposals:versioning and discussion:versioning

[snip]

On developer tools and mime-types, subversion will treat application/ecmascript as binary.

subversion.tigris.org/faq.html#binary-files

Subversion treats the following files as text: Files with no svn:mime-type Files with a svn:mime-type starting "text/" Files with a svn:mime-type equal to "image/x-xbitmap" Files with a svn:mime-type equal to "image/x-xpixmap"

All other files are treated as binary, meaning that Subversion will: Not attempt to automatically merge received changes with local changes during svn update or svn merge Not show the differences as part of svn diff Not show line-by-line attribution for svn blame

a little OT, but nevermind

two basic thing

  1. application/ecmascript;version=5 is not necesary a mimetype the full tag is <meta http-equiv="Content-Script-Type" content="application/ecmascript;version=4">

and I think this would be interpreted as plain text mimetype

  1. even if all that was causing svn to see those files as binary you can still force the mimetype by editing autoprops in your subversion config

for ex: [auto-props] *.es = svn:eol-style=native; svn:mime-type=text/plain *.es3 = svn:eol-style=native; svn:mime-type=text/plain *.es4 = svn:eol-style=native; svn:mime-type=text/plain

# Steven Mascaro (17 years ago)

Ian Hickson wrote:

Another reaction is that there are ES4 source fragments that /can/ be parsed by ES3 compilers, but whose meaning will silently be something completely different in the two versions of the language. Here are some:

// a generator expression in ES4, a loop calling a function // in ES3

function f(x) { for ( i=0 ; i < 10 ; i++ ) yield (f(), i) }

// (artificial) three statements in ES3, two in ES4

x = this function f(x) { x++ }

I think this is very dangerous, and unwise, in the context of the Web. I strongly believe that if we want to have success in expanding the Web platform, backwards-compatibility is critical. But that's another issue.

I agree. Lars, surely this is unacceptable by your very own reasoning --- because there will be ES3 code that will run in ES4, but with silently different behaviour.

# Lars Hansen (17 years ago)

-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Steven Mascaro Sent: 16. mai 2008 22:34 To: es4-discuss at mozilla.org Subject: Forwards-compatible syntax proposal

Ian Hickson wrote:

Another reaction is that there are ES4 source fragments that /can/ be

parsed by ES3 compilers, but whose meaning will silently be something

completely different in the two versions of the language.
Here are

some:

// a generator expression in ES4, a loop calling a function // in ES3

function f(x) { for ( i=0 ; i < 10 ; i++ ) yield (f(), i) }

// (artificial) three statements in ES3, two in ES4

x = this function f(x) { x++ }

I think this is very dangerous, and unwise, in the context of the

Web.

I strongly believe that if we want to have success in expanding the Web platform, backwards-compatibility is critical. But that's

another issue.

I agree. Lars, surely this is unacceptable by your very own reasoning --- because there will be ES3 code that will run in ES4, but with silently different behaviour.

I don't know what hixie is getting at exactly (whether he's referring to

the first or the second example). I've spent some time examining compatibility between ES3 and ES4 [1]. Opt-in to ES4 keeps you out of most trouble.

--lars

[1] www.ecmascript.org/es4/spec/incompatibilities.pdf

# Steven Mascaro (17 years ago)

On Sat, May 17, 2008 at 3:21 PM, Lars Hansen <lhansen at adobe.com> wrote:

Another reaction is that there are ES4 source fragments that /can/ be

parsed by ES3 compilers, but whose meaning will silently be something

completely different in the two versions of the language. Here are

some:

// a generator expression in ES4, a loop calling a function // in ES3

function f(x) { for ( i=0 ; i < 10 ; i++ ) yield (f(), i) }

// (artificial) three statements in ES3, two in ES4

x = this function f(x) { x++ }

I think this is very dangerous, and unwise, in the context of the Web.

I strongly believe that if we want to have success in expanding the Web platform, backwards-compatibility is critical. But that's another issue.

I agree. Lars, surely this is unacceptable by your very own reasoning --- because there will be ES3 code that will run in ES4, but with silently different behaviour.

I don't know what hixie is getting at exactly (whether he's referring to

the first or the second example).

I'd imagine both examples.

I've spent some time examining compatibility between ES3 and ES4 [1]. Opt-in to ES4 keeps you out of most trouble.

That's true if the programmer in question is confident that she's writing pure ES4 code. But if she's already comfortable with ES3, she will very likely want to move over to ES4 gradually, learning any new syntax bit by bit. In that case, she will want to write/copy ES3 code that will run in an ES4 interpreter (much like a C programmer might write/copy C code to be compiled by a C++ compiler). If the interpretation of code changes between ES3 and ES4, she will almost certainly encounter bugs that are very difficult to track down.

More generally, I don't believe that requiring developers to opt in to a new revision of a language/format/protocol/etc. is a good idea, which is one reason why I consider backwards-compatibility critical. I'd be interested to hear Hixie's reasons.

# liorean (17 years ago)

On Sat, May 17, 2008 at 3:21 PM, Lars Hansen <lhansen at adobe.com> wrote:

I've spent some time examining compatibility between ES3 and ES4 [1]. Opt-in to ES4 keeps you out of most trouble.

2008/5/17 Steven Mascaro <subs at voracity.org>:

That's true if the programmer in question is confident that she's writing pure ES4 code. But if she's already comfortable with ES3, she will very likely want to move over to ES4 gradually, learning any new syntax bit by bit. In that case, she will want to write/copy ES3 code that will run in an ES4 interpreter (much like a C programmer might write/copy C code to be compiled by a C++ compiler). If the interpretation of code changes between ES3 and ES4, she will almost certainly encounter bugs that are very difficult to track down.

You're basically saying that ES4 mustn't change the meaning of any ES3 program here. The problem I see with that is that it wouldn't allow any semantics expansion that reuses the old syntax forms. You'd confine all language changes to be either pure standards library ones (which are not entirely safe either, considering that there may be code in the wild that use these names and objects that are "safe" to use in ES3) or new syntactic forms that will be guaranteed to produce a syntax error in ES3, which means they can't exist in present ES3 code.

I don't agree. ES4 must be allowed to correct broken things in ES3 in case that may provide security/privacy/integrity/compatibility/sensibility improvements;such as making sure algorithms don't use hijackable global objects by making those global objects {DD, RO, DE}; or improve broken mechanisms like format control characters stripping (a clear case of trying to be clever and think forward misfiring); or introducing new identifier-like operator keywords which can take an expression operand (e.g. the yield example Lars gave).

Opt-in gives you a choice, to check your code for a short list of things that would produce a difference in ES3 as compared to ES4. With no opt-in, you don't allow that to happen.

More generally, I don't believe that requiring developers to opt in to a new revision of a language/format/protocol/etc. is a good idea, which is one reason why I consider backwards-compatibility critical. I'd be interested to hear Hixie's reasons.

In the case of programming languages, I'd much prefer an opt-in than a model that:

  • Doesn't allow correcting obvious mistakes in earlier versions.
  • Doesn't allow patching privacy/integrity problems by adding restrictions on present standards library properties.
  • That forces all semantics additions to introduce new syntactic forms in order to not modify the semantics of certain programs, for example by prohibiting adding new operators and keywords.
# Steven Mascaro (17 years ago)

liorean wrote:

You're basically saying that ES4 mustn't change the meaning of any ES3 program here. The problem I see with that is that it wouldn't allow any semantics expansion that reuses the old syntax forms. You'd confine all language changes to be either pure standards library ones (which are not entirely safe either, considering that there may be code in the wild that use these names and objects that are "safe" to use in ES3) or new syntactic forms that will be guaranteed to produce a syntax error in ES3, which means they can't exist in present ES3 code.

With respect to libraries, this isn't the case. Python handles this quite well and before ES4, so did Javascript. So long as a language allows you to redefine new behaviour back to the old behaviour (ideally, limited to specific code blocks), there's no problem. ES4 stymies these efforts by making some built-ins read-only, which I've already argued is a mistake. (One which I'm guessing will take decades to remedy for some application areas.)

Syntax is a different matter. Real changes in syntax behaviour (like swapping the meaning of '+' and '*') will cause real problems. I'm not suggesting such changes never be made (if the existing behaviour is universally considered disastrous, obviously it needs to change). Just that they rarely be changed. Indeed, Lars's doc on incompatibilities contains several examples of 'Bug Fixes That Were Not Made' (Sec 5.2) solely for compatibility reasons. Is compatibility not also the reason that 'for each' and 'let' exist in ES4, rather than just fixing 'for' and 'var'? (And yet, I would be OK if 'var' did change in meaning, because the new meaning would mostly be a superset.)

In particular, any real change to syntax behaviour that falls into the "Wouldn't it be nice if..." category should not be made if there's no easy way to provide compatibility for older versions (such as some drop-in macros) or if the change is very low-impact. If you want to implement those ideas, by all means do it, but do it in a new language. That's the easiest and least confusing way to provide opt-in.

I don't agree. ES4 must be allowed to correct broken things in ES3 in case that may provide security/privacy/integrity/compatibility/sensibility improvements;such as making sure algorithms don't use hijackable global objects by making those global objects {DD, RO, DE}; or improve broken mechanisms like format control characters stripping (a clear case of trying to be clever and think forward misfiring); or introducing new identifier-like operator keywords which can take an expression operand (e.g. the yield example Lars gave).

Supposing that I agreed the new security model was necessary, then there'd still be no problem so long as security violations committed by older code throws an error in newer interpreters. According to Lars's doc, this won't occur in ES4 for read-only, but for the life of me, I don't know why.

Wrt format control characters, the change in behaviour is very close to a superset, so I don't see any problem. In any event, the behaviour wasn't universal to begin with.

New identifier-like keywords aren't as big a problem as you'd think. Lars's example of 'yield' is a case-in-point. In ES3, his syntax indicates a function call --- which means the developer has defined a function somewhere with the name 'yield'. This should throw an error in ES4 (I'm not sure if it actually does). Hence, there would be no silent change of meaning. The use of 'class', 'let', 'package', 'public', etc. keywords would similarly throw errors (or were already reserved anyway).

(Incidentally, where many say 'hijackable global objects', I say 'redefinable built-in utilities'.)

Opt-in gives you a choice, to check your code for a short list of things that would produce a difference in ES3 as compared to ES4. With no opt-in, you don't allow that to happen.

Yes, I completely agree that if semantics change significantly (and silently), you need opt-in.

In the case of programming languages, I'd much prefer an opt-in than a model that:

  • Doesn't allow correcting obvious mistakes in earlier versions.

Real languages that are used day-in day-out don't have 'obvious' mistakes. Usually, the 'mistakes' are differences in philosophy or just awkward syntax.

  • Doesn't allow patching privacy/integrity problems by adding restrictions on present standards library properties.

While I don't like it, you can do it and keep compatibility, so long as you throw errors.

  • That forces all semantics additions to introduce new syntactic forms in order to not modify the semantics of certain programs, for example by prohibiting adding new operators and keywords.

No, you can certainly add new operators and keywords. And you can reuse old operators and keywords too, so long as they throw errors in old/new interpeters under the right conditions.

Yes, all this puts more burden on the language developers, but there are a few (orders of magnitude) more language users than there are language developers.

# Nathan de Vries (17 years ago)

On 13/05/2008, at 10:07 AM, Ian Hickson wrote:

CSS and HTML already have the feature that they are resilient to
new syntax, I think the forward compatibility this offers is far
more valuable than the "draconian" error handling in JS today.

I'm not entirely sure that comparing the ease of forwards- compatibility of ES to CSS/HTML is fair. The side effect of dropping
foreign declarations in CSS/HTML is negligible, unlike that of
dropping entire blocks of foreign code in ES. The migration from XSLT
1.0 to 2.0 is a much more realistic comparison.

On a slightly related note, one of the options available to those
migrating XSLT 1.0 stylesheets to XSLT 2.0 (other than a full re- write) was to convert the stylesheets to 2.0 but re-use the 1.0
islands. Is this kind of code re-use going to be possible with ES4?
i.e. Can a chunk of ES4 defined in a <script type="application/ javascript;version=2" /> block interact with ES3 code defined in a
<script type="application/javascript" /> block? Has this behaviour

been decided on?

Cheers,

-- Nathan de Vries

# Mike Shaver (17 years ago)

On Mon, May 26, 2008 at 9:37 AM, Nathan de Vries <nathan at atnan.com> wrote:

i.e. Can a chunk of ES4 defined in a <script type="application/ javascript;version=2" /> block interact with ES3 code defined in a <script type="application/javascript" /> block? Has this behaviour been decided on?

Yes, that's been a major part of the design of the language; toolkits need to be able to upgrade to ES4 features without making the consumers upgrade wholesale, and vice versa.

www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf has an example of how ES4 and ES3 code styles interact, and splitting the sample program into separate <script> blocks should work just as

well as it does in with ES3 today.

Mike

# Anne van Kesteren (17 years ago)

On Mon, 26 May 2008 15:45:25 +0200, Mike Shaver <mike.shaver at gmail.com>

wrote:

On Mon, May 26, 2008 at 9:37 AM, Nathan de Vries <nathan at atnan.com>
wrote:

i.e. Can a chunk of ES4 defined in a <script type="application/ javascript;version=2" /> block interact with ES3 code defined in a <script type="application/javascript" /> block? Has this behaviour been decided on?

Yes, that's been a major part of the design of the language; toolkits need to be able to upgrade to ES4 features without making the consumers upgrade wholesale, and vice versa.

www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf has an example of how ES4 and ES3 code styles interact, and splitting the sample program into separate <script> blocks should work just as well as it does in with ES3 today.

Yet it does require changes to your deployment because I need to add
additional <script> elements or change existing ones. It would be better

if on the HTML side I could just use:

<script src=library.js>

That already works today, the type attribute default value is
text/javascript.

Given that, something what Ian suggests makes sense I think for the
transition periods to an improved version of the language.

# Nathan de Vries (17 years ago)

On 26/05/2008, at 11:45 PM, Mike Shaver wrote:

...splitting the sample program into separate <script> blocks
should work just as well as it does in with ES3 today.

By "should work" I'm hoping you mean "will work", because that's the
crux of what I'm asking :).

The main reason I'm interested in an ES4 script accessing an ES3
script (I presume the the reverse is not possible?) is that all of my
library code is ES3, and I'd like to be able to leave it as-is while
I make the switch to ES4. A simple example would be the ability to
use an ES3 library like Prototype.js from an ES4 script.

If I needed to pull all ES3 code into an ES4 script tag - and make
the bare-minimum changes - to be able to use that code in an ES4
codebase, I (and I think many others) would be a sad panda indeed. Is
behaviour like this expected to be defined in the ES spec, or is it
open to vendor interpretation?

Cheers,

-- Nathan de Vries

# Mike Shaver (17 years ago)

On Mon, May 26, 2008 at 10:07 AM, Nathan de Vries <nathan at atnan.com> wrote:

On 26/05/2008, at 11:45 PM, Mike Shaver wrote: By "should work" I'm hoping you mean "will work", because that's the crux of what I'm asking :).

I mean "will work if correctly implemented, if there are not remaining related bugs in the spec", but yeah.

The main reason I'm interested in an ES4 script accessing an ES3 script (I presume the the reverse is not possible?)

The reverse is indeed possible.

is that all of my library code is ES3, and I'd like to be able to leave it as-is while I make the switch to ES4. A simple example would be the ability to use an ES3 library like Prototype.js from an ES4 script.

Yep, that's a critical use-case.

If I needed to pull all ES3 code into an ES4 script tag - and make the bare-minimum changes - to be able to use that code in an ES4 codebase, I (and I think many others) would be a sad panda indeed. Is behaviour like this expected to be defined in the ES spec, or is it open to vendor interpretation?

Interoperating with ES3 script, bidirectionally, is a big part of the motivation for the details of the type system and other parts of the language. If there is an interoperability issue that's underspecified, I think it's just a bug in the spec, and we should fix it. Early implementations shipped to millions of web users will help identify them, as they have with various smaller changes already.

Mike

# Mike Shaver (17 years ago)

On Mon, May 26, 2008 at 9:52 AM, Anne van Kesteren <annevk at opera.com> wrote:

Given that, something what Ian suggests makes sense I think for the transition periods to an improved version of the language.

That could be, but Waldemar seems to think that it's not possible due to regexp (and E4X?) syntax. I tend to side with Waldemar on syntactic details, but I'm sure he would be as happy as me for someone to show a way around it.

Mike

# Nathan de Vries (17 years ago)

On Mon, 2008-05-26 at 10:22 -0400, Mike Shaver wrote:

The main reason I'm interested in an ES4 script accessing an ES3 script (I presume the the reverse is not possible?)

The reverse is indeed possible.

Is there any reading material you could point me to as to how this would work? I thought the entire purpose of versioned <script /> tags was to

allow vendors to evaluate one script as ES3 and another as ES4. In that context:

<script type="application/javascript"> /<![CDATA[/ var ES3ProtoClass = Class({ initialize: function() { this.es4instance = new ES4Class; } }); /]]>/ </script>

<script type="application/javascript;version=2"> /<![CDATA[/ class ES4Class() { private const es3instance;

  function ES4Class() {
    es3instance = new ES3ProtoClass();
  }
}

/]]>/ </script>

What does "new ES4Class" mean to a user agent that does not yet support ES4, or one that supports both ES3 & 4, but treats "app/javascript" as ES3.

Am I missing something?

,

-- Nathan de Vries

# liorean (17 years ago)

2008/5/27 Nathan de Vries <nathan at atnan.com>:

<script type="application/javascript"> /<![CDATA[/ var ES3ProtoClass = Class({ initialize: function() { this.es4instance = new ES4Class; } }); /]]>/ </script>

<script type="application/javascript;version=2"> /<![CDATA[/ class ES4Class() { private const es3instance;

 function ES4Class() {
   es3instance = new ES3ProtoClass();
 }

} /]]>/ </script>

What does "new ES4Class" mean to a user agent that does not yet support ES4, or one that supports both ES3 & 4, but treats "app/javascript" as ES3.

For a UA that does not support ES4, that would be a Reference Error because the latter script would be rejected from being parsed because of the content type, thus the name would not be defined

For a UA that supports both, it is not a problem - it's an ES3 [[Construct]] call. The ES3 internal [[Whatever]] functions are translated into ES4 namespaced equivalents, AIUI.

(Another way to see it is that ES4 classical inheritance and namespaces are a way to make things that ES3 uses for the host objects available in user scripts as well.)

Am I missing something?

Most of the ES4 added non-syntactic semantics would work perfectly fine in ES3 as either internal behaviour or Host objects. ES3 code obviously can't use new syntactic or expanded semantic behaviour from ES4, but if the ES4 does that internally, then ES3 does not care.

# Nathan de Vries (17 years ago)

On Tue, 2008-05-27 at 04:18 +0200, liorean wrote:

The ES3 internal [[Whatever]] functions are translated into ES4 namespaced equivalents, AIUI.

Thanks for the run-down. That makes sense.

Cheers,

-- Nathan de Vries

# Waldemar Horwat (17 years ago)

I've had a request to repeat the example I showed at the meeting, so here's one:

{ if (false) { // Say we're introducing a new cast syntax '(<expr>) <expr>' var y = (int)/fo+/.exec("abcfoo"); } push_the_button = false; { z = y/x; } }

In ECMAScript parsing and lexing are interleaved. There is no way to tell without correctly parsing a piece of code whether / starts a regexp or is a division. In the above example the regexp was meant to be /fo+/, but the syntax error recovery code will instead think that /.exec...y/x is an extended (multiline) regexp, missing the crucial closing brace of the block and the push_the_button = false statement. Many other syntax errors can lead to this kind of lexer misalignment, hence it is impossible to isolate a syntax error to the first inner block above (or any other similar syntactic construct), despite the fact that it never executes due to the if (false). You can make guesses based on indentation and such but guesses don't belong in a standard.

Waldemar