Re: Es4-discuss Digest, Vol 8, Issue 44

[Brendan Eich-2]

On Oct 30, 2007, at 6:14 PM, Brendan Eich wrote:

> ES4 provides const, fixed typename bindings, lexical scope (let),  
> program units, and optional static type checking -- all of which  
> *do* make ES4 code easier to analyze and instrument to enforce  
> security properties.

I left out the intrinsic namespace from the above litany, but Graydon  
nicely pointed it out. I wonder if it's understood from the overview,  
and from the proposal page:

http://wiki.ecmascript.org/doku.php?id=proposals:intrinsic_namespace

This message tries to summarize how intrinsic and related new ES4  
facilities such as fixtures work together to improve integrity  
against XSS threats. It's late, I hope I got everything right. My TG1  
colleagues will correct me if not. You can test in the RI to see  
intrinsic in action -- in particular, there's an intrinsic::print  
method, it's the P in our REPL.

The intrinsic namespace evolved in part from the desire to support  
opt-in early binding of standard methods, which is a feature of the  
ECMA-262 Edition 3 Compact Profile (http://www.ecma-international.org/ 
publications/standards/Ecma-327.htm). Here's how it works:

* For each standard prototype method, there is a method with the same  
unqualified (local) name, but in the intrinsic namespace. So  
Array.prototype.slice is paired with a method named intrinsic::slice  
in class Array.

* The prototype method typically calls the intrinsic method on its  
dynamic |this|, e.g.

         /* E262-3 15.6.4.3: Boolean.prototype.valueOf. */
         prototype function valueOf(this: AnyBoolean)
             this.intrinsic::valueOf();

from builtins/Boolean.es in the RI (note the expression closure  
syntax), but for Array, String, and string generics, there's a static  
generic method to delegate to from both the prototype and intrinsic  
method:

         prototype function slice(start, end)
             Array.slice(this,
                         start === undefined ? 0 : Number(start),
                         end === undefined ? Infinity : Number(end));

         intrinsic function slice(start: AnyNumber=0, end:  
AnyNumber=Infinity): Array
             Array.slice(this, start, end);

(Note the extra special logic in the prototype slice method required  
by ES3.)

The upshot is that this pairing of prototype and intrinsic methods is  
not expensive in terms of code footprint.

* The intrinsic methods are fixtures: DontDelete bindings searched  
ahead of the prototype chain.

* These methods are type-annotated with more precise argument and  
return types, e.g. while Array.prototype.slice has signature

   function (start: *, end: *): *

(not spelled out, of course: (start, end) is enough for the formal  
parameter list -- this isn't Java :-P), the Array intrinsic::slice  
fixed method has type

   function (start: AnyNumber, end: AnyNumber): Array

* Users opting into early binding use this pragma:

   use namespace intrinsic;

at the top of a program unit or block. This opens the intrinsic  
namespace so that the name slice in an expression a.slice(i, j),  
where a has type Array, will resolve as a.intrinsic::slice(i, j).

* Independent from the intrinsic namespace (and optional for  
implementations to support or treat as standard mode), but useful as  
well, one can say:

   use strict;

to run a type checker that also does basic lint-like name-binding and  
other sanity checking.

There's still some debate over how much analysis strict mode should  
do, but this mode is completely optional at the ES4 implementation's  
discretion -- no need for it on cell phones. The only run-time effect  
of strict mode is a change to eval, to prevent it from using var,  
const, or function against its caller's variable object, while  
allowing let. This prevents eval from clobbering caller bindings  
(function can replace an existing binding in ES3), and it avoids  
injection of novel eval-created bindings into the dynamic scope.

The model for strict mode other than the lint-like sanity checks is  
partial evaluation, so there is no difference other than the above  
eval restriction in runtime semantics if a program makes it past  
strict mode, compared to runtime semantics in standard mode. Thus  
strict mode simply prevents certain programs that might run (possibly  
even run correctly) from reaching run-time.

* It isn't just prototype methods that have intrinsic-qualified fixed  
method counterparts: class static methods such as Date.parse, the  
Math object's methods, and familiar top-level functions such as  
parseInt and hashcode, also have intrinsic counterparts. So too do  
the built-in operator generic functions (a.k.a. multimethods), e.g.  
intrinsic::=== which goes with intrinsic::hashcode like peas and  
carrots: see the Map proposal at http://wiki.ecmascript.org/doku.php?
id=proposals:dictionary.

The benefits include faster method lookups in lightweight  
implementations, better type error detection at compile time thanks  
to the more precise intrinsic function types, and of course the main  
point Graydon made: integrity. You can be sure nothing has replaced a  
standard library binding in the mutable global object or a standard  
prototype.

Beyond intrinsic, as I mentioned previously, there are tools for  
library authors to tame the global object and other mutable object  
hazards in the language:
* const and block scope (let) provide immutable bindings and block-
wise isolation/shadowing.
* The global properties Object, Array, etc. are constant in ES4.
* Type annotations on function definitions constrain the binding of  
the function name to have a compatible type.
* const function can be used to prevent the value as well as the type  
of the binding from being changed later.
* And of course, the static type checker available if an  
implementation supports 'use strict' can find type errors, which can  
point to security holes.

Verification is a linchpin for further analyses that I expect to be  
researched (hybrid information flow, e.g.) on top of ES4, and where  
the research yields solid results, we hope to incorporate that  
knowledge into future editions of the standard. Reasoning about ES4  
code is thus easier, or even possible in the first place, compared to  
ES3 code which requires conservative static analysis or else hybrid  
static and dynamic (runtime instrumentation) techniques.

All of these facilities were added for several good reasons,  
verification but also integrity among them. This was done while  
preserving backward compatibility of ye olde mutable global object  
and standard prototypes. It may be that these facilities are simply  
not well understood. I hope it's clear now that they address, as best  
those of us working together in TG1 know how, the hazards of the  
mutable global object -- while not breaking the web. Any questions?

/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Yuh-Ruey Chen]

As far as I can see it, there are a couple of non-technical issues here
that have to be resolved, but they all boil down to who is willing to
implement what. Is there truly no way to compromise?

MS says that they think ES4 deserves to a be a new language. Suppose
that is true and ES4 is renamed, say ES++. Then would MS be willing to
implementing ES++ in their new browser? Or is the name truly a scapegoat
to blame their misgivings of ES4 the language itself?

Or if you consider the feature set of ES4 to be too bloated, that ES4 is
trying to tackle problems it was never meant to handle, what exactly do
you dislike about ES4? What features would do you want to cut out of the
language? What features would the pro-ES4 people be willing to cut out?
I know this will be hard, but let's ignore feature dependencies for the
moment. Say, for example, that you dislike the class system but are fine
with the type system (as nonsensical as that sounds). Perhaps you're
fine with grafting a type system on top of the prototype system without
classes. Or if you also dislike the type system, what do you propose
instead? For encapsulation, you might propose sticking with closures.
Now, how are you going to address the pitfalls of closures, namely
memory usage and inefficiency? ES4 advocates may also be concerned that
encapsulation via closures is plain ugly, while ES4 critics say that
classes make the language inelegant. Perhaps there is another solution?
Anyway, do you see where I'm getting with this? There should be some
room for compromise. I'd like to see some active discussion concerning
these feature disagreements.

Lastly, all this accusations concerning intentions need to stop.
Mozilla, this concerns you too - I find that saying you won't let big
bully MS block ES4 is somewhat hypocritical, considering that the SVG
1.2 committee did something similar to you guys (make no mistake, I'm
not accusing anyone and I hope this is the last time SVG is mentioned on
this mailing list). In any case, hypocritical or not, all these
accusations are not constructive at all. Responding to accusations with
more accusations is plain sophomoric in my book. Please, I have enough
of my political bullshit from the news - I don't expect that here.

Thanks, Yuh-Ruey Chen
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Nov 2, 2007, at 2:40 PM, Yuh-Ruey Chen wrote:

Lastly, all this accusations concerning intentions need to stop.

In the absence of technical arguments, these are inevitable.

Mozilla, this concerns you too - I find that saying you won't let big

bully MS block ES4 is somewhat hypocritical, considering that the SVG

1.2 committee did something similar to you guys (make no mistake, I'm

not accusing anyone and I hope this is the last time SVG is mentioned on

this mailing list).

If you mean SVG Tiny 1.2 violating W3C process rules by skipping from Working Draft to Candidate Recommendation without addressing all received technical objections, there's no comparison. We working on ES4 could use some specific technical objections from the Ecma members who oppose ES4. I promise we wouldn't ignore any before moving ES4 to the final stage of Ecma standardization (there is no CR analogue in Ecma).

Hey, you brought this up -- no fair doing a drive-by about SVG while I'm in earshot! :-)

In any case, hypocritical or not, all these

accusations are not constructive at all. Responding to accusations with

more accusations is plain sophomoric in my book. Please, I have enough

of my political bullshit from the news - I don't expect that here.

If these are inevitable because technical objections haven't been made, that tells you something important. The politics are overriding technical considerations. Act accordingly, but please, don't assume there is a technical fix to a political problem. Forcing one by a bartering process will only make a Franken-standard.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss