Forwards-compatible syntax proposal

[Steven Mascaro]

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.