gmane.comp.lang.javascript.ecmascript4.general

Internationalization API: Collator sensitivity

Norbert Lindenberg — 2012-05-16T21:34:05

In recent discussions between Markus Scherer, Nebojša Ćirić, Mark Davis (Google), Eric Albright (Microsoft) and myself, a few issues around the sensitivity option of the Collator constructor in the ECMAScript Internationalization API [1, section 11.3.2] have come up. It would be good to get input from a wider audience.

1) The "variant" sensitivity: This name isn't very descriptive. When "variant" is selected, a collator has to take all differences between input strings into account that it considers at the "case" and "accent" levels; it may consider additional differences. New names have been proposed:
- "accent+case": mnemonic, but doesn't indicate that additional differences may be considered.
- "common"
- "normal"
- "default": doesn't work because it's not actually the default in all cases.
- "full": doesn't work because implementations aren't required to take all differences into consideration.
- "distinct", "dissimilar", "varied", "inherent", "intrinsic", "essential": not really descriptive.

An alt

Re: "Remaining Hazards and Mitigating Patterns of Secure Mashups inECMAScript 5"

Mark S. Miller — 2012-05-16T13:44:52

On Tue, May 15, 2012 at 11:45 PM, Brandon Benvie
<brandon-cj2k9yrovAx2xNJEPvMZDgC/G2K4zDHf< at >public.gmane.org>wrote:



What does

    [06:40:52.788] Error: Failed to preserve wrapper of wrapped native weak
map key. < at > http://bbenvie.com/lab/shadow/meta-objects.browser.js:947

mean? I saw this as the first thing on the console when run on FF
Nightly 15.0a1 (2012-05-05)

Re: "Remaining Hazards and Mitigating Patterns of Secure Mashups inECMAScript 5"

Mark S. Miller — 2012-05-16T13:46:30

Sorry, not the first thing on the console. I didn't notice the setting of
the scroll bar elevator.

On Wed, May 16, 2012 at 6:44 AM, Mark S. Miller <erights-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: "Remaining Hazards and Mitigating Patterns of Secure Mashups inECMAScript 5"

Brandon Benvie — 2012-05-16T06:45:32

http://bbenvie.com/lab/shadow is an example of what you can do using
Proxies (look in the console). That's loading jQuery (unmodified) into a
membrane wrapping everything.
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: "Remaining Hazards and Mitigating Patterns of Secure Mashupsin ECMAScript 5"

Aymeric Vitte — 2012-05-15T22:26:38

Finally I could hear the talk (++ "too bad that the end is missing")

Then I took a look mainly at domado.js, startSES.js, repairES5.js

Quite clever, but quite complicate...

I did focus on cajaVM.eval and tried to theorically follow its process 
with an example as described below, with some small simplifications 
since security is one thing but the final result of VM processing 
(whether security is involved or not) is interesting too

Maybe it will be undigest for other readers since it is difficult to 
summarize if you do not have all the code, but again it's quite smart as 
js allows (even if I have some doubts about performances with all the 
getters and setters, and even with proxies being added later to help 
this), I hope my understanding is correct, the exercise is not just a 
"vue de l'esprit", I have something in mind since some time related to 
this and other things that I might submit, maybe to simplify a little bit.

function compileExpr(exprSrc, opt_sourcePosition) {
   var wrapperSrc = secur

Re: catch vs function scope; var declaration vs initialization

Brendan Eich — 2012-05-15T00:09:00

Thanks for pointing this out. It is a fairly recent regression. I used 
`hg bisect` to find it and filed

https://bugzilla.mozilla.org/show_bug.cgi?id=755099

I agree with Allen, we should clear this dark corner of the deck with 
vigorous application of early-error solution and scrub in nightly builds 
to prove no real code relies on var e; inside catch (e) {...} hoisting.

/be

Re: catch vs function scope; var declaration vs initialization

Allen Wirfs-Brock — 2012-05-14T22:14:59

On May 14, 2012, at 2:44 PM, Claus Reinke wrote:

An analogy with inner functions isn't needed and wouldn't be correct.  This is simply appling the static semantics of Block level declarations. A Block  is not allowed to var declare (including via nested blocks) any identifier that is lexically declared in the block (but not including nested blocks).

function f() {
   try { throw "hi"
   } catch (e)  {
      var v;
   };
}

is legal and binds "v" at the top-level of function f.  If the catch clause was treated like an anonymous function, "v" would be bound at the level of the catch clause.  It isn't...

In terms of scope contours the above is equivalent to 

function f() {
  {  //throw "hi"
     }
  {
      let e;
      var v;
   }
}

Allen




_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: catch vs function scope; var declaration vs initialization

Claus Reinke — 2012-05-14T21:44:19

Yes, please!-)


'let' vs 'var' would have been my next question. Good to
know that this particular issue does not propagate to 'let'!


Even better!-) And in line with treating catch as an anonymous function.

Claus

Re: catch vs function scope; var declaration vs initialization

Claus Reinke — 2012-05-14T21:43:31

In "practice" (as in: what implementations permit; not: what is used),
there is also this variation:

try { throw "oops" }
catch (f) {
    function f() { console.log(f) }
    console.log(f)
}
console.log(f)

This isn't permitted in ES5, and 'f' would be block-scoped if permitted
in ES6. In common non-standard extensions to ES5, the function and
references to 'f' in its body are bound outside the catch. I don't even
want to look at what happens with a function declaration in a catch
where the body references the catch parameter..

I'm currently looking at these edge cases for implementing
renaming (program transformation) - no fun.


Which means that the single occurrence of 'e' in 'var e = "ho"' is bound
to two different scopes: outside the catch for creating a binding, in the
catch for assignment. As Allen anticipated, I was wondering about the
effects on mixing 'let' and 'var', too.

Claus

Re: Concise Function Body

Allen Wirfs-Brock — 2012-05-14T17:08:07

On May 14, 2012, at 9:53 AM, Brendan Eich wrote:


AssignmentExpression :
   ...
   ArrowFunction

ArrowFunction :
   ArrowParameter => ConciseBody

Re: Concise Function Body

Allen Wirfs-Brock — 2012-05-14T16:53:50

I'm pretty sure there was some discussion about this on some thread, but it may have been fleeting...

Concise methods (http://wiki.ecmascript.org/doku.php?id=harmony:concise_object_literal_extensions#methods ) have been proposals for quite some time.

When I added ArrowFunctions into the draft, it seemed to make sense to consistently apply them to the other new function definition form (concise methods) that we already had added. Once that was done, it also made sense, from a consistency standpoint, to permit them for get/set properties.

This means there is a simple rule: function definition using the keyword function always have a bracketed body.  All other forms of function definition use ConciseBody which allows for either an assignment expression or a bracketed body.

I'm happy to debate this if there is any disagreement, that's why we have spec. drafts.  Nothing is set in stone.  

Allen



On May 14, 2012, at 9:31 AM, Erik Arvidsson wrote:


all fixed...

_____________________________________________

Re: Concise Function Body

Brendan Eich — 2012-05-14T16:53:42

 From where is this produced? It's unsound if from MemberExpression 
(ES1-5) or PrimaryExpression (ES6) -> FunctionExpression -> ... ConciseBody.

/be

Erik Arvidsson wrote:

Concise Function Body

Erik Arvidsson — 2012-05-14T16:31:48

The latest ES6 draft introduced the notion of a concise function body
and it is being used for arrow functions as well as for methods and
set/get accessors.

Grammar:

ConciseBody :
  [lookahead does not include { ] AssignmentExpression
  { FunctionBody }

Example:

var object = {
  get x() this._x,
  set x(v) this._x = v,
  method() this._x
};

I don't remember us ever discussing this change?

Personally I think it makes things more consistent since concise
function bodies are allowed in ArrowFunction but I've heard people
complain about it already.

p.s. Allen, the spec draft has a bunch of ConsiseBody typos.

Re: catch vs function scope; var declaration vs initialization

John J Barton — 2012-05-14T16:24:27

I believe that -- if we had any practical way to measure this --
'most' web developers would expect 'ho undefined hu'. This is the
sensible output, the one given by ie9. It is sensible because the
simple synopsis of the funky var rules is "variables get values when
assignments are executed".  In my opinion the spec-ed answer here is
less useful to developers than the ie9 answer.  It may be true that
specifications which allowed the sensible answer would result in other
more serious nonsense of course.

jjb

Re: catch vs function scope; var declaration vs initialization

Allen Wirfs-Brock — 2012-05-14T15:50:17

undefined undefined hu 

is what should be produced according to the spec. 

Divergence among implementations is a good sign that there is an opportunity to clean up this particular mess. 

The current ES6 draft requires an early error for this function because it is trying to hoist a var declaration across a block-level declaration of the same identifier.  EG,

function f() {
    {
        let x=1;  //early error let declaration of x in a block that contains a nested var declaration of x
        {
             var x=2;
        }
    }
}

Because let is a new feature, this restriction doesn't introduce any backwards compatibility issues. However, for consistency, the draft also currently applies the same let declaration restrictions to catch parameters.  Your experiment suggests that that we might actually be able to to that ...

Allen





On May 14, 2012, at 2:57 AM, Claus Reinke wrote:

Re: Reflect.parse (from RE:typeof null)

Claus Reinke — 2012-05-14T10:48:02

I was merely stating my personal impression. It is difficult to pin
down all the bits of information that contributed to that impression,
but here are some of them:

- not all JS parsers document their AST, but it appears that the 
    SpiderMonkey AST has the largest number of (partial) 
    implementations; most parsers have their own AST (jslint
    and jshint might share their AST by forking) but
    SpiderMonkey, esprima, PanPG, reflect.js, jstr
    all refer to the same AST document.

    Of those, esprima seems the most active. The combination of
    Reflect.parse awareness and esprima being an efficient cross-
    browser implementation is certainly the reason why I think 
    that this AST spec is in the process of winning.

- even though I've moved to JS relatively recently, I've already
    worked with 3 different JS parsers and have written one myself; 

    it just isn't funny anymore: all of them had different ASTs
    and varying support, and I was still missing out on one popular
    JS pars

Re: catch vs function scope; var declaration vs initialization

T.J. Crowder — 2012-05-14T10:25:07


That was my analysis as well.

§10.5 tells us that `var` creates bindings in the anonymous function's
environment, so the function's env has `e`, `o`, and `u` bindings.

§12.14 tells us that within the `catch`, a new environment is created with
the function's environment being the parent. So the assignment to `e` is to
the `catch`'s `e`, not the function's.

Annotating that code a bit:

(function(){
    var e; // Where these actually happen
    var o;
    var u;

    try {
        throw "hi";
    } catch (e) {
        e = "ho"; // Assigns to the `catch` env's `e`
        o = "hu"; // Assigns to the function's `o`
        console.log(e);
    }
    console.log(e, u, o); // Expect undefined undefined "hu"

}());

Re: catch vs function scope; var declaration vs initialization

Peter van der Zee — 2012-05-14T10:11:17

Inside the catch, the catch-scope is first for reading and writing.
But the catch scopes are ignored for declaring new variables. So your
expectation seems to be the correct one. `e` is created in the scope
of the anonymous function. Likewise, `o` and `u` are created in that
scope too (so neither throw at the second console.log). "ho" is
assigned to the catch-scope `e`, since that's the first scope in the
scope traversal lookup at that point. Catch scopes are weird, yo.

- peter

catch vs function scope; var declaration vs initialization

Claus Reinke — 2012-05-14T09:57:55

What should be the output of the following code?

(function(){

try {
  throw "hi";
} catch (e) {
  var e = "ho";
  var o = "hu";
  var u;
  console.log(e);
}
console.log(e,u,o);

}());

It seems clear that the first console.log should output 'ho'.
Implementations seem to disagree on the second console.log, 
though.

From my current understanding of the spec, I expected: 

    undefined undefined 'hu'

which I consider unfortunate; especially the first 'undefined'
was intended to demonstrate the bad effects of separating 
declaration from initialization while treating catch and function 
differently, in terms of scoping.

node, opera: undefined undefined 'hu'

firefox 12 complains: 'e is not defined'

ie 9 outputs: houndefinedhu

It looks as if firefox misses the hoisted declaration of 'e'
(it doesn't complain about 'u', only about 'e') while ie9 
somehow merges the declaration and the catch parameter.

Claus

Re: The new operator

Brendan Eich — 2012-05-14T04:26:16

Indeed the primal sin in JS, a combination of "make it look like (and in 
Netscape 3 interface with [LiveConnect with] Java)" and me being in a 
hurry and taking shortcuts, is primitive types that are not rationalized 
up front as objects.

We can fix over time, though. Let typeof wither (it will die hard) and 
promulgate a constructor.name-based string-valued "type" function. But 
as Allen and I keep saying, avoid the nominal-type-overquerying 
anti-pattern, per Smalltalk.

/be

Re: The new operator

Axel Rauschmayer — 2012-05-14T02:18:20


I like that they can be introduced in a stepwise fashion (whenever that may be...): Numbers first, user-defined value object types later. Numbers should complement the binary data proposal nicely.