Discussion of ECMAScript 4.

Oliver Hunt | 10 Feb 23:48

Re: proto security


On Feb 10, 2012, at 2:29 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Feb 10, 2012, at 11:24 AM, Brendan Eich wrote:
>> 
>>> Hi Tom, this may repeat parts of replies from others, if so please bear with me:
>>> 
>>> I think __proto__ should be a bit magical, and in particular should not be proxy-able. Annex B is
becoming "Normative Optional", meaning you are not required to implement its contents to conform to
ECMA-262, but if you do support the specified APIs, then Annex B's spec is normative.
>> 
>> A different approach is to tie the semantics to language syntax instead of making it part of the "virtual
machine" that is defined by the internal methods.  For example, I could specify the [[Prototype]]
mutating behavior of an assignment to the __proto__ property as an extension to the evaluation semantics
of the simple assignment operator (11.13.1).  An advantage to doing it this way is that it can only be
trigger by using that specific syntactic form.  In particular, other syntactic constructs that in do
[[Put]]'s and all the [[Put]]'s in built-in and host functions would not trigger it.
> 
> Some engines do use syntactic specialization, in particular I recall Rhino doing that. But do web-facing
engines that support __proto__ do that? What do they do with o['__proto'+'__'] and the like? Anyone know?

The only rules we have in JSC wrt syntactic identification of __proto__ are to prevent people from naming
functions __proto__ :D

> 
> 
>> The approach I took in my proposal for the handling of __proto__ in object literals is another example of
this syntactic approach.
>

(Continue reading)

headers

Nebojša Ćirić | 10 Feb 23:28

i18n (Intl/Globalization) tests

I wrote couple of tests for test262/intl402 suite and they are in my local Mercurial copy. I still don't have commit access to the main repository so I can't upload them. But before we start the process:

1. Should somebody independent (non-Microsoft, non-Google, non-Amazon) write tests following the spec only?

2. I expect large amount of conflicts and files being named in slightly off way between Microsoft and Google. We could avoid file naming clash by producing initial structure in Mercurial that covers all chapters/sub-chapters, like test262/intl402/ch8.4/ch-8.4.2.js.

3. What header/licence should be on top? I see only Microsoft and Sputnik (being obsolete) licences in test262 files.

--
Nebojša Ćirić

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

headers

Allen Wirfs-Brock | 10 Feb 21:30

Re: proto security

On Feb 10, 2012, at 11:24 AM, Brendan Eich wrote:

> Hi Tom, this may repeat parts of replies from others, if so please bear with me:
> 
> I think __proto__ should be a bit magical, and in particular should not be proxy-able. Annex B is becoming
"Normative Optional", meaning you are not required to implement its contents to conform to ECMA-262, but
if you do support the specified APIs, then Annex B's spec is normative.

A different approach is to tie the semantics to language syntax instead of making it part of the "virtual
machine" that is defined by the internal methods.  For example, I could specify the [[Prototype]]
mutating behavior of an assignment to the __proto__ property as an extension to the evaluation semantics
of the simple assignment operator (11.13.1).  An advantage to doing it this way is that it can only be
trigger by using that specific syntactic form.  In particular, other syntactic constructs that in do
[[Put]]'s and all the [[Put]]'s in built-in and host functions would not trigger it.

The approach I took in my proposal for the handling of __proto__ in object literals is another example of
this syntactic approach. 

This sort of approach really focuses limiting the "damage"  (or magic, if you prefer) to the actual source
code use cases that we feel must be supported for interoperability and limits the spread of the contagion .

> 
> For __proto__ we do not need to over-specify (as we generally do elsewhere, for interoperation). The
appearance of a data property matches some implementations today and it could be spec'ed as Allen wrote
up. This adds some risk to the main spec and proxies, but if we do not want __proto__ to be proxy-able then it
might be the right approach.
> 
> The temptation to polish __proto__ to fit the spec and language is high but my gut says we should resist it.
We may help enshrine it in ways we do not want (proxies). We may err in inventing a new de-jure spec that does
not match existing implementations.

But I think we do want to have a way to disable this feature, even though that capability does not exists (at
least consistently) in existing implementations.

The existence of a Object.prototype.__proto__ property (perhaps a special one) seems like a plausible
way to do this this.  On the other hand, there is also nothing preventing us from simply specify a new global
function __proto__disable__ (or any other triggering mechanism we might agree on)that could be called
to disable the __proto__ feature.

We can under specify Object.prototype.__proto__  but doing so clearly opens up the at least the
possibility of hypothetical interpretability  issues of the sort we have historically tried to
eliminate from the specificatiion.  The fact, that nobody has brought forward any examples of such
interoperability problems among the current somewhat divergent implementations of __proto__ shows
th't the current differences aren't an issue so we could probably get away with it.  But it does seem like a
slippery slope. If we decide it is ok to under-specify here what about the next time there is a difference of
option or preference about the edge cases manifested by some new functionality (say, just as an example,
closure capture in the initializer expressions of for(let;;) loops). Are we going to be 
 more inclined to just under-specify?  I hope not.

Allen

headers

Allen Wirfs-Brock | 10 Feb 17:14

Re: proto security

On Feb 10, 2012, at 3:46 AM, Tom Van Cutsem wrote:

> Hi,
> 
> I'm also in favor of exposing __proto__ as an accessor on the grounds that it is least magical. I'm worried
that the changes made here to the core internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and
[[Delete]] will give proxies a hard time to properly emulate this behavior if they would want to do that.
How would a proxy handler be able to access the internal variable UnderscoreProtoEnabled?

function UnderScopeProtoEnabled() {
   var p={};
   return Object.getPrototypeOf({__proto__:p})===p;
}

I believe the root question is whether we are willing to expose for arbitrary usage a function that is able to
modify the [[Prototype]] of any object.  EG:

    Object.setPrototypeOf = function (obj,proto) {Object.getOwnPropertyDescriptor(Object.getPrototypeOf({}),"__proto__").set.call(obj,proto)};

Once we have don this, that function can be used in arbitrary places, including as or within get and set
functions of any accessor property with any name on any object.

> 
> (I currently assume that in any event, aProxy.__proto__ would just trigger the "get" trap for
"__proto__" and that all of this magical behavior does not apply to proxies, only built-in normal objects.)

Presumably.  

> 
> Also +1 to Gavin's proposed alternative to the frame-check.

Yes, Gavin check amounts to the same thing  as mine, once you allow for differences in how we define Object.prototype.__proto

The important ifference is whether that check is make in the internals of a function that is visible as an
accessor get function or whether the check is hidden inside the implementation of the standard internal methods.

Allen

headers

Peter van der Zee | 10 Feb 11:27

Fallback

There's currently no way of introducing anything new into the language
that breaks syntax. I think that point has been made very clearly with
harmony/es6. Can we introduce a way to make these transitions easier
in the future?

CSS has a very simple way of gracefully ignore rules it doesn't know.
In CSS you can specify rules and features and whatever the engine
doesn't understand, it will ignore gracefully and continue. While this
obviously won't work out of the box for js. But I think we can work
around it. In CSS this is scoped to individual rules. In js there's no
notion of rules (and "lines" won't work either) but you could talk
about functions or modules (or blocks?) in the same way. I think
modules are a bit too big scoped for this but I'd like to discuss the
generic idea first. We can always bikeshed over the syntax later. I'll
work with function-like syntax for now.

Say a browser wanted to support a new keyword. Right now, that's
impossible to even experiment with unless you write an entire engine
in js and have a duplicate source code for fallback. You simply can't
do something like

x ||= y;

without breaking the code permanently and without exception. We can
only add stuff that fits perfectly within the existing grammar.
There's also no way for a vendor to implement this as an experiment
because it will still break in older versions of the browser or other
vendors. So what if we could do something like this?

function foo(x,y){
  "if es7";
  return x ||= y;
  "/es7";
} // the "/directive" serves as a delimiter because otherwise you'd
never know where to stop parsing when you don't support it
if (!foo) {
  var foo = function(){
    x = x || y;
    return x;
  }
};

So now you have a way to experiment with the new extension and a
simple way of extending the language permanently, while still having
backwards compat (at least up to the point that we introduce this
system), graceful failures and a proper way of figuring out a
fallback. If a vendor did not support the feature asked for it could
declare `foo` as null or something allowing easy support detection.

The declared function should work within the existing js language of
course and should be callable from within js with the regular
mechanics. This includes stuff like call, apply, and bind. Whatever
the function itself does with the arguments or the context is up to
the implementation. Whatever it returns should again be a proper js
value. This allows you to easily fallback to an "es5" function because
the fingerprint would be the same (and besides, I have no idea how
else this could work otherwise anyways).

This also could allow introduction of vendor prefixes. However, for
now I'd like to focus on the general principle though and leave the
prefix discussion for later.

Some syntax possibilities:

function foo(){ "es7"; x ||= y; }
function foo(){ "es7"; x ||= y; "/es7"; }
condFunction foo(){ "es7"; x ||= y; }
condFunction "es7" foo(){ x ||= y; }
condFunction "es7" foo(){ x ||= y; } "es7";

Personally, I'd prefer a function-scoped capability over a
module-scoped capability because I think I'd like to apply this to
smaller snippets rather than an entire module. Or maybe both.

Open things for me:
- How to efficiently specify the (scope of) things you want to opt-in to?
- How to limit the problem with interoperability this would
undoubtedly cause (even with prefixes).
- Proper keyword/syntax for this, would still like to keep this js-ish
- Is nesting desirable? Reasonably feasible? Especially wrt the delimiter
- This system would also allow for non-js extensions (like
coffeescript or even ruby/etc), is that a problem?

If we think such a system is viable and we can find a simple way of
introducing it to the language, we should do it sooner than later. The
sooner it's in, the less "stuck" we will be in the future.

- peter

headers

Nebojša Ćirić | 9 Feb 00:58

I18n clarification needed for 8.4.5 [[LookupSupportedLocalesOf]]

I am not sure what result we expect from LookupSupportedLocalesOf.

Thy way I read the spec is that if user passes requestedLocales = ['sr-Latn-RS'] and supportedLocales = ['sr'] then we would return ['sr-Latn-RS'].

I feel it would be more useful to return the actual supported locale, in this case ['sr'].

Implementation wise it's trivial to get either one of those.

--
Nebojša Ćirić

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

headers

Mark S. Miller | 8 Feb 22:47

Fwd: Paper on Proxies

Enjoy!

---------- Forwarded message ----------
From: Tom Van Cutsem <tvcutsem-t4LwSHXjkAOzQB+pC5nmwQ@public.gmane.org>
Date: Wed, Feb 8, 2012 at 1:12 PM
Subject: Paper on Proxies
To: TC39 <e-tc39 <at> ecma-international.org>

Hi,

I recently finished a paper (co-authored with MarkM) that spells out the details of the design of (direct) proxies and the reflection API. [...]

I've also written up the story behind the paper here:
http://soft.vub.ac.be/~tvcutsem/invokedynamic/esharmony_reflect

[...] it's published as a techreport [...], so feel free to circulate.

Cheers,
Tom

--
Cheers,
--MarkM

Attachment (vub-soft-tr-12-03.pdf): application/pdf, 332 KiB

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

headers

Claus Reinke | 8 Feb 22:19

modules: import hiding, and usage patterns

Just saw this wiki update (*)

    http://wiki.ecmascript.org/doku.php?id=harmony:modules&do=diff&1328732818

and this sentence:

    If there is a conflict between the names from two distinct imports,
    and exactly one of the imports uses the ''*'' form, then the other
    import takes precedence.

I have two issues with this:

- implicit override instead of ambiguity warning/error
    (add an explicit import, and change semantics of implicit
    imports elsewhere in the current module, without a type
    system to catch the change)

- no way to filter items from the "*" form
    (can't resolve ambiguities explicitly)

I would prefer a way to resolve such ambiguities explicitly
by selectively hiding imports (import * hiding {x,y} from M),
with warnings/errors for unresolved ambiguities.

If there is going to be an implicit "import *" from a standard
prelude, it would also be good to have a way to turn the
implicit import into an explicit import (with selective hiding).

Great to see updates to the modules proposal - could you
please have a look at the module usage patterns outlined in

    supporting ES upgrading with a programming pattern repo?
    https://mail.mozilla.org/pipermail/es-discuss/2011-November/018240.html

It would be nice to see how these patterns will be handled
by ES6 modules (I hope the answer isn't always "use loaders",
but JS coders seem to have grown used to dynamic module
usage patterns which don't seem covered by the static aspects
of ES6 modules).

Finally, about the wiki: the list of old page revisions for each
proposal links to page revisions, not to diffs - am I missing
something, or could the wiki be configured to add diff links
(to previous revision)? Also, the RSS feed still has escaped
URLs, so the links do not lead to the intended page (*).

Claus

(*) the wiki RSS feed url escape problems still persist:
    https://mail.mozilla.org/pipermail/es-discuss/2011-April/013927.html

headers

Herby Vojčík | 7 Feb 19:56

Explicit local copies (was: Re: lexical for-in/for-of loose end)


Andreas Rossberg wrote:
>>> let a = [], b = [], c = [], d = []
>>> for (int i = 0, f = function(){ return function() { ++i } }; i<  10;
>>> d[i] = function() { return i }, ++i) {
>>>   a[i] = f;
>>>   b[i] = f();
>>>   c[i] = function(){ return i }
>>> }
>
> But note that the environment in b's closures is not the for-loop
> environment. Instead, it is a local environment, whose parent is the
> for-loop environment. To make that case work, it is not enough to be
> able to modify the [[Scope]] environment of closures -- in general,
> you'd need to swap out arbitrary parts of an environment chain.

Oww, that's a problem. Copies are hard here... refs can do it, but no 
one likes them.

> I am fine with either. So far I have favoured
> fresh-variables-per-iteration, but the current discussion has raised
> some doubts in the back of my mind.

This whole discussion leads me to completely different opinion: what 
about to embrace "explicit is better than implicit" for this case, and 
allow let/const without initializer to create local copy of an outer 
variable?

Then, if you need to capture a value, you write it down (I know this 
appeared to avoid capturing by hand in (function (i) { ... })(i), but 
reusing normal blocks to do it may work, wouldn't it?

It disallows some of the ninjutsu (init-closures will work with 
different i than localized closures), but it will be clearly visible:

   let a = [], b = [], c = [], d = [], e = []
   for (int i = 0, f = function(){ return function() { ++i } }; i<  10;
     d[i] = function() { return i }, ++i) {
     a[i] = f; // this
     b[i] = f(); // and this
     c[i] = function(){ return i } // and this work with loop-level i
     {
        let i;
        e[i] = function () { return i; } // this has local i
     }
   }

> /Andreas

There can be even shorter syntax, like
        e[i] = function () let i { return i; } // this has local i
or
        e[i] = function () { let i; return i; } // this has local i
whoch can avoid need of {} block, but it must be thought of if it is 
possible consistently (the former should, the latter may be questionable).

Herby

headers

Norbert Lindenberg | 7 Feb 19:27

Globalization API: Prototype objects

The current specification of the ECMAScript Globalization API requires the prototype objects for the
LocaleList, Collator, NumberFormat, and DateTimeFormat constructors to be objects constructed by
these constructors themselves. This is following a pattern established in the ECMAScript Language
Specification, which requires the Date prototype object to be a Date object, the RegExp prototype object
to be a RegExp object, etc.

At the November TC 39 meeting, there were some comments that this is not the recommended pattern anymore.
Instead, prototype objects should be minimal objects with just those properties (mostly methods) that
all constructed objects should inherit.

Which way should the Globalization API go?

Regards,
Norbert

headers

Allen Wirfs-Brock | 7 Feb 03:51

Re: lexical for-in/for-of loose end

On Feb 6, 2012, at 5:32 PM, Brendan Eich wrote:

> Grant Husbands wrote:
>> Now, there are some advantages and disadvantages:
> 
> Thanks for expanding on your and Herby's proposals, it helps. A disadvantage on its face of "Herby's
init-swap" is that variables are copied from iteration scope to iteration scope, *and* all contained
closures need their [[Scope]] adjusted every iteration.
> 
> For the code you evaluate "Herby's body-swap" against, the "flat closure" (Chez Scheme "display
closure") formation is indeed good optimization. The closure passed to setTimeout post-dominates the
only live (from its point of view) assignments to i, so copying i's value into the closure allows very fast
access and no scope entrainment at all.
> 
> A harder case would mutate upvars after the closure is evaluated, so that it must capture references not
values. In any case, the scope would need to be cloned on each iteration where closures formed, and those
closures' [[Scope]] internal properties updated.
> 
> Allen should comment on whether this attempt to square the circle (kidding, mostly) might fly in the spec.
Implementors while secondary should weigh in too.

My sense is that we could make these schemes works in spec. space.  Either by allowing bindings that have
References as values or by adding new mechanisms such environment cloning.  

It actually sounds fun and perhaps even the "right thing" to do.  However,  I have some doubts concerning
whether the added work and spec. complexity is really justified by the benefit.  Maybe, but there are lots
seemingly more important things to work on.

With "body-swap" it concerns me a bit that is an arbitrary and variable number of closures may need to be
updated each iteration (consider a body containing a while loop that spits out closures that capture init bindings.)

For both, I need to think about whether it may be possible (and the impact) for a closure activation
(containing a generator?) to span a iteration boundary.

Allen

202	February 2012
1143	January 2012
311	December 2011
1011	November 2011
876	October 2011
497	September 2011
238	August 2011
561	July 2011
766	June 2011
903	May 2011
421	April 2011
617	March 2011
177	February 2011
216	January 2011
221	December 2010
205	November 2010
182	October 2010
192	September 2010
46	August 2010
186	July 2010
132	June 2010
258	May 2010
171	April 2010
14	March 2010
161	February 2010
177	January 2010
324	December 2009
97	November 2009
75	October 2009
236	September 2009
91	August 2009
70	July 2009
201	June 2009
257	May 2009
41	April 2009
213	March 2009
183	February 2009
193	January 2009
295	December 2008
249	November 2008
310	October 2008
336	September 2008
499	August 2008
266	July 2008
128	June 2008
166	May 2008
245	April 2008
526	March 2008
184	February 2008
110	January 2008
89	December 2007
195	November 2007
262	October 2007
105	September 2007
115	August 2007
96	July 2007
23	June 2007

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29

Re: __proto__ security

i18n (Intl/Globalization) tests

Re: __proto__ security

Re: __proto__ security

Fallback

I18n clarification needed for 8.4.5 [[LookupSupportedLocalesOf]]

Fwd: Paper on Proxies

modules: import hiding, and usage patterns

Explicit local copies (was: Re: lexical for-in/for-of loose end)

Globalization API: Prototype objects

Re: lexical for-in/for-of loose end

Re: proto security

Re: proto security

Re: proto security