Re: Jan 18 meeting notes

[Andrea Giammarchi]

+1 for the returned class ... also if we distinguish between "array" and
"Array" then the new Boolean/Number/String case can be covered via
"Number", if object, rather than "number", which is cool.

Th only weird thing would be "object" rather than "Object", as if its
[[class]] is unknown

br

On Fri, Jan 20, 2012 at 5:39 AM, Axel Rauschmayer  wrote:

> > So Object.type is the thing to draft. Probably it should return
> typeof-like strings with the "null" fix and only that. I do not believe it
> should start returning "array" for Array instances, or take other
> experimental risks. But we should discuss.
>
> FWIW: I’ve written down all typeof use cases that I could come up with:
> http://www.2ality.com/2012/01/typeof-use-cases.html
>
> A way of returning [[class]] would be great. Any reason why such a
> function couldn’t be merged with Object.type()? My attempt at implementing
> such a merged function (along with a detailed rationale – I prefer
> returning "Array" to returning "array") is documented here:
> http://www.2ality.com/2011/11/improving-typeof.html
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does private(expr) create a private storage block?

[Andrea Giammarchi]

On Fri, Jan 20, 2012 at 2:24 AM, Herby Vojčík  wrote:

>
> Let the object created is foo. When calling foo.method(), it is accessing
> private(foo), not private(objectWithPrivates), since this is foo. "If yes"
> does not happen. Errors may happen since foo probably does not have private
> space (my proposal in this thread is touching this issue).
>

Object.create accept the __proto__ and a descriptor, I am not sure a
descriptor will/should ever have a private(this) configured unless there is
not a class for the descriptor but the list of configurations won't make
much sense, i.e.

{value: function () { this instanceof OuterClass /* not possible, it's just
an object */ }}





>
> I did not understand this question.



similar to what you are thinking about private.{prop} ... you answered
already

thanks and br
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: January 19 meeting notes

[Jon Zeppieri]

On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eich  wrote:
>
> Yes kids, this means we are going with MarkM's lambda desugaring from:
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html

Is there a version of this desugaring that deals with recursive
bindings in the initializer expression of the loop?

In my post 
(https://mail.mozilla.org/pipermail/es-discuss/2008-October/007826.html),
I used an example like:

   for (let fn = function() { ... fn(); ...};;)

There are other, related cases, like:

  for (let [i, inc] = [0, function() {i++;}]; i < n; inc()) ...

In that earlier post, I wrote that "the modifications [to MarkM's
desugaring] needed to make these work are pretty straightforward,"
though I can't recall what I had in mind at the time.

Waldemar's option (above) solves the recursive function case, but not
the local-inc case. Even as the loop rebinds i and inc, the latter
will continue to refer to (and increment) the initial binding of i.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: January 19 meeting notes

[Axel Rauschmayer]

> The downside, if it is a downside, is that if you take a literal C/C++ point 
> of view, and change
> 
> let a = [];
> for (let i = 0; i < 10; i++) {
> a.push(function () { return i; });
> }
> for (let j in a) {
> assert(a[j]() === j);
> }
> 
> into
> 
> let a = [];
> {
> let i = 0;
> for (; i < 10; i++) {
> a.push(function () { return i; });
> }
> }
> 
> then the assert-loop will have to change:
> 
> for (let j in a) {
> assert(a[j]() === 10);
> }
> 
> but that's what you asked for. for(let ...;;) is a special form.


Right. The choice between explicitly copying and explicitly sharing. The former 
being awkward and sharing still being available makes it look like the right 
decision.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: January 19 meeting notes

[Sam Tobin-Hochstadt]

On Thu, Jan 19, 2012 at 8:20 PM, Axel Rauschmayer  wrote:
> Given that this desugaring will only kick in if a closure leaves the loop
> (right?), this is a case of automatically doing the right thing (and only if
> it’s warranted).
>
> Yes kids, this means we are going with MarkM's lambda desugaring from:
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html

The difference between this behavior and the current behavior should
only be observable when capturing the environment with a closure (or
maybe with a direct eval), so in many cases nothing changes.
-- 
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: January 19 meeting notes

[Brendan Eich]

Axel Rauschmayer 
January 19, 2012 8:20 PM
Given that this desugaring will only kick in if a closure leaves the 
loop (right?), this is a case of automatically doing the right thing 
(and only if it’s warranted).


Right, it's not observable without a closure.

The downside, if it is a downside, is that if you take a literal C/C++ 
point of view, and change


let a = [];
for (let i = 0; i < 10; i++) {
a.push(function () { return i; });
}
for (let j in a) {
assert(a[j]() === j);
}

into

let a = [];
{
let i = 0;
for (; i < 10; i++) {
a.push(function () { return i; });
}
}

then the assert-loop will have to change:

for (let j in a) {
assert(a[j]() === 10);
}

but that's what you asked for. for(let ...;;) is a special form.

/be



--
Dr. Axel Rauschmayer
a...@rauschma.de 

home: rauschma.de 
twitter: twitter.com/rauschma 
blog: 2ality.com 

Brendan Eich 
January 19, 2012 8:02 PM

Yes kids, this means we are going with MarkM's lambda desugaring from:

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html

So any closures formed in the body of such a for(let...;...;...) loop 
will capture the binding created afresh for that iteration. This 
avoids the nasty need for CoffeeScript "do" or the expanded JS 
equivalent of an IIFE surrounding the closure to create per-iteration 
storage for a copy of the loop control variable.


Contrary to Jon Zeppieri's good argument at

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007826.html

that

{
let x = 0;
for (; x< n; x++) ...
}

should have different behavior than

for (let x = 0; x< n; x++) ...

those of us left from the TC39 meeting (missing a few reps, short of 
quorum) favored the greater-good argument ofprogrammer who follow'let 
is the new var' and who form closures in loops benefiting from the 
fresh let binding being captured, instead of one binding per loop 
where the likely value of the binding is the terminating loop control.


Yay (I'm pretty sure).

/be
Waldemar Horwat 
January 19, 2012 4:40 PM
Second day meeting notes.

Revisited octal/binary constants.
Waldemar: Note that we currenty allow both upper and lower cases for 
a, b, c, d, e, f in hex literals as well as e in exponents and x in 
hex literals. Breaking symmetry by forbidding upper case for b and o 
to avoid lookalikes would be "nanny language design". We can't forbid 
lookalikes anyway:

{
let y = 3;
{
let у = 7;
return y;
}
}
This is a valid ES6 strict function body that returns 3, of course. 
The second let defines a local variable named with a Cyrillic letter.


Decision: Allow upper case B and O to start binary or octal literals.

Complex discussion about what's feasible in static checking of 
references from modules. Discussed issues with integrating script code 
eval'd from cross-origin XHR requests and the (anti-)merits of using 
var to declare globals.


MarkM: Abandon static checking.
Waldemar: MarkM's example from yesterday is an important use case: 
using a typeof check to see if a variable is defined and later in the 
same module conditionally dynamically defining it if it wasn't and, 
even further down in the module, using it. A static check would flag 
the uses and prevent the module from loading.

Allen: This is a good use case for pragmas.

MarkM, Waldemar: Example of a successful strict transition: Nowadays 
the two of us don't even know non-strict Perl because it's too weird. 
We learned the cleaner strict version, always set the pragma, and stay 
within the strict version. Anything non-strict is considered to be 
broken until it can be upgraded to strict.


Philosophical discussion about modality, whether a "mode" should be 
called a "dialect", etc.


Summary of static checking pain points that need resolutions:
- Out-of-order asynchronously loaded scripts
- Concatenation of scripts
- Dynamic testing for variable existence and conditional use if it exists
Resolution: Will do more work and come back to this area.

Allen: Do top-level let and const create properties of the global object?
DaveH (channeling Andreas): No, but functions do.
Sam: If they don't then the T-shirt Erik is currently wearing wouldn't 
work.

Many agreed that we can't break the T-shirt.
DaveH: What if there are duplicate top-level bindings?
MarkM: Top-level let should behave as much as possible the same as 
concatenated scripts.

Waldemar: What about read-eval-print loops?
MarkM: Each eval inserts one more nested scope.
Waldemar: What if someone does this:
> let x = 3;
> function foo() {return x;}
> let x = 7;
This would leave foo returning 3.
MarkM: That's the proper behavior. Anything else has problems.
Waldemar: [incredulous]
Allen: We shouldn't spec read-eval-print loops.

DaveH's summary of issues:
- Can we get to a world where var is completely unnecessary?
- Can we do the above for all important top-

Re: January 19 meeting notes

[John J Barton]

2012/1/19 Kevin Reid 

> On Jan 19, 2012, at 19:40, Waldemar Horwat wrote:
>
> > Waldemar:  What about read-eval-print loops?
> > MarkM:  Each eval inserts one more nested scope.
>

This is not what users of REPL want or expect.


> > Waldemar:  What if someone does this:
> > > let x = 3;
> > > function foo() {return x;}
> > > let x = 7;
> > This would leave foo returning 3.
> > MarkM:  That's the proper behavior.  Anything else has problems.
>

Developers expect these lines to be part of a program they happened to type
in, in the same scope.


> > Waldemar:  [incredulous]
> > Allen:  We shouldn't spec read-eval-print loops.
>

The scope issues above are complicated by the need to augment the scope
with REPL-specific values, aids to using the environment interactively. The
simple way to implement REPL is eval, the simple augmentation is
"with(REPL-stuff){ ...}"

So we have a feature highly prized by JS developers based on two languages
features unloved on es-discuss: maybe Allen is on to something ;-).


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

Re: Jan 18 meeting notes

[Axel Rauschmayer]

> So Object.type is the thing to draft. Probably it should return typeof-like 
> strings with the "null" fix and only that. I do not believe it should start 
> returning "array" for Array instances, or take other experimental risks. But 
> we should discuss.

FWIW: I’ve written down all typeof use cases that I could come up with:
http://www.2ality.com/2012/01/typeof-use-cases.html

A way of returning [[class]] would be great. Any reason why such a function 
couldn’t be merged with Object.type()? My attempt at implementing such a merged 
function (along with a detailed rationale – I prefer returning "Array" to 
returning "array") is documented here:
http://www.2ality.com/2011/11/improving-typeof.html

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: January 19 meeting notes

[Axel Rauschmayer]

Given that this desugaring will only kick in if a closure leaves the loop 
(right?), this is a case of automatically doing the right thing (and only if 
it’s warranted).

> Yes kids, this means we are going with MarkM's lambda desugaring from:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html
> 
> So any closures formed in the body of such a for(let...;...;...) loop will 
> capture the binding created afresh for that iteration. This avoids the nasty 
> need for CoffeeScript "do" or the expanded JS equivalent of an IIFE 
> surrounding the closure to create per-iteration storage for a copy of the 
> loop control variable.
> 
> Contrary to Jon Zeppieri's good argument at
> 
> https://mail.mozilla.org/pipermail/es-discuss/2008-October/007826.html
> 
> that
> 
> {
>let x = 0;
>for (; x<  n; x++) ...
> }
> 
> should have different behavior than
> 
> for (let x = 0; x<  n; x++) ...
> 
> those of us left from the TC39 meeting (missing a few reps, short of quorum) 
> favored the greater-good argument ofprogrammer who follow'let is the new var' 
> and who form closures in loops benefiting from the fresh let binding being 
> captured, instead of one binding per loop where the likely value of the 
> binding is the terminating loop control.
> 
> Yay (I'm pretty sure).

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: January 19 meeting notes

[Brendan Eich]

Waldemar Horwat 
January 19, 2012 4:40 PM

Discussion about scope of for-bindings.
for (var x = ...;;) {...}  will, of course, retain ES1 semantics.
for (let x = ...;;) {...}
Allen: This will behave as in C++: x is bound once in a new scope 
immediately surrounding just the for statement.
DaveH: Strangely enough, this creates a new x binding in Dart at each 
iteration.
There's an alternative semantics that creates an iteration-local 
second x inside the loop and copies it back and forth.  Debate about 
whether to go to such complexity.  Many of us are on the fence.
Waldemar: What happens in the forwarding semantics if you capture the 
x inside a lambda in any of the three expressions in the head?

If this happens in the initializer:
DaveH's option: The lambda would capture an outer x.
Alternative: The lambda captures a hidden second x.
Waldemar's option: The lambda would capture the x from the first 
iteration.  The let variable x is bound once through each iteration, 
just before the test, if

  for (let x = expr1; expr2;) {...}
were:
  while (true) {
let x = first_iteration ? expr1 : value_of_x_from_previous_iteration;
if (!expr2)
  break;
...
  }
MarkM:  Just discovered that his desugaring has the same semantics as 
Waldemar's option.


for (const x = ...;;) {...}  behaves analogously to let, whatever we 
decide let will do.


Those opposed earlier to new-binding-per-iteration hop back onto the 
fence.  Waldemar, Brendan, and DaveH hop off the fence to now support 
it, as it will cure an annoying gotcha in practice.  Looks like we 
have support for it now.


Yes kids, this means we are going with MarkM's lambda desugaring from:

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html

So any closures formed in the body of such a for(let...;...;...) loop 
will capture the binding created afresh for that iteration. This avoids 
the nasty need for CoffeeScript "do" or the expanded JS equivalent of an 
IIFE surrounding the closure to create per-iteration storage for a copy 
of the loop control variable.


Contrary to Jon Zeppieri's good argument at

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007826.html

that

{
let x = 0;
for (; x<  n; x++) ...
}

should have different behavior than

for (let x = 0; x<  n; x++) ...

 those of us left from the TC39 meeting (missing a few reps, short of 
quorum) favored the greater-good argument ofprogrammer who follow'let is 
the new var' and who form closures in loops benefiting from the fresh 
let binding being captured, instead of one binding per loop where the 
likely value of the binding is the terminating loop control.


Yay (I'm pretty sure).

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

Re: Does private(expr) create a private storage block?

[Herby Vojčík]

I can answer how I understood, but I am not the proposer...

Andrea Giammarchi wrote:

   1. what's the expected behavior with mixins ( borrowed method from
  different classes ) ?


Each class has its own private scope, that is, private in borrowed 
method is in different "plane of existence" than private in actual class.



   2. what if Object.create(objectWithPrivates, descriptor) ? would
  descriptor methods be able to invoke objectWithPrivates.method()
  with private(this) access in the function body? If yes, would that
  private(this) refer to the objectWithPrivates? This would violate
  the objectWithPrivates private concept, isn't it?


Let the object created is foo. When calling foo.method(), it is 
accessing private(foo), not private(objectWithPrivates), since this is 
foo. "If yes" does not happen. Errors may happen since foo probably does 
not have private space (my proposal in this thread is touching this issue).



   3. are privates exportable? method() {return private(this)}


Not (if not throwing error, it should simply return this).


   4. are private properties, not private anymore once extracted,
  exportable? method(){return private(this).whatever}


This works as expected. This does not mean it is not private. It is 
readable via method, but not settable, so it still a private property, 
but with value published.



   5. what about a single block in the Class definition such private {c,
  i = 0, storage = {}, whatever} so that these are pre defined in a
  single place and callable across the class scope without requiring
  usage of private(this) but bound to the current context rather
  than shared across all instances?


I did not understand this question.


More may come up soon :-)

br


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

Re: January 19 meeting notes

[Kevin Reid]

On Jan 19, 2012, at 19:40, Waldemar Horwat wrote:

> Waldemar:  What about read-eval-print loops?
> MarkM:  Each eval inserts one more nested scope.
> Waldemar:  What if someone does this:
> > let x = 3;
> > function foo() {return x;}
> > let x = 7;
> This would leave foo returning 3.
> MarkM:  That's the proper behavior.  Anything else has problems.
> Waldemar:  [incredulous]
> Allen:  We shouldn't spec read-eval-print loops.

In case it is relevant to the ‘problems’, I would like to remind MarkM that E 
used to behave in the return-7 way at REPL, and we abandoned it not because it 
wasn't nice REPL behavior but only because it meant that anything defined at 
top-level was forced to not be deep-frozen due to it closing over those 
slightly magic variables, but that is not an issue here since JavaScript 
doesn't have deep-frozen-in-that-sense functions.

(I'm not advocating returning 7; I’m just checking that 3 is returned for valid 
reasons.)

-- 
Kevin Reid  

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

Re: Block lambda is cool, its syntax isn't

[Axel Rauschmayer]

Playing devil’s advocate: The main benefit of having a function shorthand in 
addition to block lambdas is that minimizers profit from it, right? For the use 
case that you showed, I wouldn’t mind at all to type the slightly longer 
"function". I most mind function expressions as parameters (for, say, 
Array.prototype.forEach) where lambda blocks are perfect.


On Jan 19, 2012, at 22:47 , François REMY wrote:

> Yet they are cases where a block lambda isn’t suited and where a ‘classic’ 
> function is just too long to type (and would hurt performance as well). Look 
> back in the thread for a sample. (Mainly: cases involving a ‘return’ in a 
> loop or in a nested statement can’t be solved well using block-lambda).
>  
> Block lambda is not the solution since it wasn’t written to solve the cases 
> where we traditionnaly use a 'local function’, but to solve new use-cases 
> where we want our function to continue to run inside a function structure, or 
> asynchronously. The old cases where we use “function() { ... { ... return; } 
> ... }” are not covered properly by block lambda, nor are intended to.
>  
> From: Axel Rauschmayer
> Sent: Thursday, January 19, 2012 10:14 PM
> To: Brendan Eich
> Cc: Andreas Rossberg ; François REMY ; Oliver Hunt ; es-discuss Steen
> Subject: Re: Block lambda is cool, its syntax isn't
> FTR: With block lambdas and object literal extensions, I wouldn’t want/need a 
> function shorthand.


-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: Jan 18 meeting notes

[Andrea Giammarchi]

give typeof its role and leave Array.isArray, Object.isObject,
Function.isFunction ... Whaveter.isWhatever it's easy to implement logic :-)

For classes it's fine to me to keep using the
{}.toString.call(something).slice(8, -1) trick ( Rhino engine as exception
but ... they can align with "[object " + [[Class]].name + "]" here )

for what I have seen, typeof has been always mainly used to grant an object
like reference, with the boring null exception ... I don't think developers
will complain about missing "array" also because I would expect typeof new
Number to be "number" at that point but this is misleading until primitives
exist

"function" is a must have because developers want to know about [[Call]] so
here comes the ambiguity problem between typeof and Object.isObject but
once these global public static methods are there I would keep typeof
simple/backward compatible as it has always been

br

OT: also with direct proxy Function.prototype could have a get(key) able to
/^is([A-Z][a-zA-Z$_]*)$/.test(key) return the right check for the generic
global/userDefined constructor through {}.toString.call(value).slice(8, -1)
=== RegExp.$1 check ... never mind, just random thoughts :-)


On Fri, Jan 20, 2012 at 1:20 AM, Brendan Eich  wrote:

> Andrea Giammarchi 
> > >
>> January 19, 2012 4:10 PM
>>
>> for all WeakMap shims and examples I have seen this to guard the key as
>> object is basically:
>>
>> Object.isObject = function isObject() {
>>  return Object(value) === value;
>> };
>>
>> why such difference with indeed function ambiguity with your first
>> example?
>>
>
> We agreed not to treat functions as non-"isObject" objects.
>
>
>> Agreed on Object.type since it's easy to monkey patch while typeof is
>> already causing my code to look like this
>>
>> typeof obj != "null" && typeof obj == "object" && !!obj
>>
>
> V8-proofing shows this, yeah. It's a good warning sign in addition to the
> sheer runtime incompatibility of changing typeof null to be "null".
>
> So Object.type is the thing to draft. Probably it should return
> typeof-like strings with the "null" fix and only that. I do not believe it
> should start returning "array" for Array instances, or take other
> experimental risks. But we should discuss.
>
> /be
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

January 19 meeting notes

[Waldemar Horwat]

Second day meeting notes.

Revisited octal/binary constants.
Waldemar: Note that we currenty allow both upper and lower cases for a, b,
c, d, e, f in hex literals as well as e in exponents and x in hex
literals.  Breaking symmetry by forbidding upper case for b and o to avoid
lookalikes would be "nanny language design".  We can't forbid lookalikes
anyway:
{
  let y = 3;
  {
let у = 7;
return y;
  }
}
This is a valid ES6 strict function body that returns 3, of course.  The
second let defines a local variable named with a Cyrillic letter.

Decision:  Allow upper case B and O to start binary or octal literals.

Complex discussion about what's feasible in static checking of references
from modules.  Discussed issues with integrating script code eval'd from
cross-origin XHR requests and the (anti-)merits of using var to declare
globals.

MarkM: Abandon static checking.
Waldemar:  MarkM's example from yesterday is an important use case: using a
typeof check to see if a variable is defined and later in the same module
conditionally dynamically defining it if it wasn't and, even further down
in the module, using it.  A static check would flag the uses and prevent
the module from loading.
Allen: This is a good use case for pragmas.

MarkM, Waldemar:  Example of a successful strict transition:  Nowadays the
two of us don't even know non-strict Perl because it's too weird.  We
learned the cleaner strict version, always set the pragma, and stay within
the strict version.  Anything non-strict is considered to be broken until
it can be upgraded to strict.

Philosophical discussion about modality, whether a "mode" should be called
a "dialect", etc.

Summary of static checking pain points that need resolutions:
- Out-of-order asynchronously loaded scripts
- Concatenation of scripts
- Dynamic testing for variable existence and conditional use if it exists
Resolution:  Will do more work and come back to this area.

Allen:  Do top-level let and const create properties of the global object?
DaveH (channeling Andreas):  No, but functions do.
Sam:  If they don't then the T-shirt Erik is currently wearing wouldn't
work.
Many agreed that we can't break the T-shirt.
DaveH:  What if there are duplicate top-level bindings?
MarkM:  Top-level let should behave as much as possible the same as
concatenated scripts.
Waldemar:  What about read-eval-print loops?
MarkM:  Each eval inserts one more nested scope.
Waldemar:  What if someone does this:
> let x = 3;
> function foo() {return x;}
> let x = 7;
This would leave foo returning 3.
MarkM:  That's the proper behavior.  Anything else has problems.
Waldemar:  [incredulous]
Allen:  We shouldn't spec read-eval-print loops.

DaveH's summary of issues:
- Can we get to a world where var is completely unnecessary?
- Can we do the above for all important top-level patterns?
- Can we do the above without ever needing nonstrict mode?
- Should let have consistent semantics in all contexts?
Consensus on:
- Should multiple scripts or scripts and attributes share lexical scopes
other than via global objects?  No.
- Consensus that concatenating multiple scripts via scope nesting semantics
is undesirable.

Sam:  What about global scope polluters?
let Object = 7;
should be an error.  But implementations have other sources of polluters
(such as predefined implementation features or other HTML elements on the
page) that can cause global clashes.
Allen:  Top-level declaration overriding is allowed if the existing
property has the attributes writable:true and enumerable:true (and the new
declaration stays enumerable).  Configurable doesn't (sic) enter the
decision.
Allen:  See https://bugs.ecmascript.org/show_bug.cgi?id=78
DOMs now declare properties on the prototype of the Window object.

Internationalization report
Discussion about a name (and domain name) for the internationalization test
suite.  402 is the current next unused ECMA standard number.  We probably
shouldn't wait for two more ECMA standards to be published  Mild
consensus on putting the test suite in a subdirectory of test262.
Discussion about whether to keep internationalization as a separate
document or to merge it into ECMA-262.  Current decision is to keep it
separate for faster evolution of both standards and to avoid bureaucracy
with ISO.
Discussion about the choice of name for the global variable via which the
internationalization API is accessed.  Possibilities are Globalization and
Intl.  Need to look for web breakage these would cause.
Everybody needs to review internationalization spec before the vote in
March.

Debate over whether to use TypeError or RangeError for domain errors.
DaveH:  Use TypeError
Allen, Waldemar:  Use RangeError.  Note that RangeError is used for more
than just numeric intervals -- passing 3.5 to a function that expects an
integer in [0, 2^32) throws a RangeError in ES5.1.

Test262 status report:  No invalid test cases left.
MarkM: Want some means to avoid having test262 penalize implementations
th

Re: Does private(expr) create a private storage block?

[Andrea Giammarchi]

as a reference could replace "this" for privates and would make even
reading code easier ... private(this) as concept is OK but in practice is
misleading quite a lot ( looks an invoke unrelated with "unique" current
object as argument )

+1 then for private.whatever

On Fri, Jan 20, 2012 at 1:29 AM, Herby Vojčík  wrote:

> Andrea Giammarchi wrote:
>
>>
>>
>> On Fri, Jan 20, 2012 at 1:05 AM, Herby Vojčík > > wrote:
>>
>>P.S.: I posted another thread with proposal for shortcut for
>>private(this), but it still did not reach the list (I see
>>private(this) as non-elegant, too).
>>
>> -1 to private(this) here too ... but specs are outdated so maybe it's
>> already private.{definition} in the constructor which imo would look
>> more elegant
>>
>
> Exactly that syntax is in my not-yet-on-the-list proposal
> (private.whatever instead of private(this).whatever).
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does private(expr) create a private storage block?

[Herby Vojčík]

Andrea Giammarchi wrote:



On Fri, Jan 20, 2012 at 1:05 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:

P.S.: I posted another thread with proposal for shortcut for
private(this), but it still did not reach the list (I see
private(this) as non-elegant, too).

-1 to private(this) here too ... but specs are outdated so maybe it's
already private.{definition} in the constructor which imo would look
more elegant


Exactly that syntax is in my not-yet-on-the-list proposal 
(private.whatever instead of private(this).whatever).

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

Re: Jan 18 meeting notes

[Brendan Eich]

Andrea Giammarchi 
January 19, 2012 4:10 PM
for all WeakMap shims and examples I have seen this to guard the key 
as object is basically:


Object.isObject = function isObject() {
  return Object(value) === value;
};

why such difference with indeed function ambiguity with your first 
example?


We agreed not to treat functions as non-"isObject" objects.


Agreed on Object.type since it's easy to monkey patch while typeof is 
already causing my code to look like this


typeof obj != "null" && typeof obj == "object" && !!obj


V8-proofing shows this, yeah. It's a good warning sign in addition to 
the sheer runtime incompatibility of changing typeof null to be "null".


So Object.type is the thing to draft. Probably it should return 
typeof-like strings with the "null" fix and only that. I do not believe 
it should start returning "array" for Array instances, or take other 
experimental risks. But we should discuss.


/be

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

Re: Does private(expr) create a private storage block?

[Andrea Giammarchi]

On Fri, Jan 20, 2012 at 1:05 AM, Herby Vojčík  wrote:

>
> P.S.: I posted another thread with proposal for shortcut for
> private(this), but it still did not reach the list (I see private(this) as
> non-elegant, too).
>


-1 to private(this) here too ... but specs are outdated so maybe it's
already private.{definition} in the constructor which imo would look more
elegant
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Jan 18 meeting notes

[Andrea Giammarchi]

for all WeakMap shims and examples I have seen this to guard the key as
object is basically:

Object.isObject = function isObject() {
  return Object(value) === value;
};

why such difference with indeed function ambiguity with your first example?

Agreed on Object.type since it's easy to monkey patch while typeof is
already causing my code to look like this

typeof obj != "null" && typeof obj == "object" && !!obj

which looks a bit pleonastic ( since you like the word ) for code that
would like to run cross milestone and understand if the object is an object
and not a function ... however, now that I wrote it I understand concerns
about Object.type and the function case ...

br

On Fri, Jan 20, 2012 at 12:54 AM, Brendan Eich  wrote:

> David Bruant 
>> January 19, 2012 1:15 AM
>>
>> Le 19/01/2012 02:27, Waldemar Horwat a écrit :
>>
>>> Brendan: Kill typeof null.  Replace it with Ojbect.isObject?
>>>
>> What would be the semantics of this?
>>
>
> It was not obvious but the precedent stems from the strawman that led to
> my proposal to change typeof null:
>
> http://wiki.ecmascript.org/**doku.php?id=strawman:object_**
> isobject&rev=1295471005
>
> This week we considered the draft spec:
>
>  Object.isObject = function isObject(value) {
>  return typeof value === 'object'&&  value !== null;
>  }
>
>
> to be deficient because a function is also an object, so one might rather
> have
>
>  Object.isObject = function isObject(value) {
>  return (typeof value === 'object'&&  value !== null) || typeof value
> == 'function';
>
>  }
>
>
>  --
>> Object.isObject(null); // false
>> Object.isObject({}); // true
>> // so far so good :-)
>> Object.isObject(function(){}) // ?
>> --
>> I'd like to advocate "true" for the last case. For now, the best way to
>> test if something is of type Object (as defined in ES5.1 - 8.6, so
>> including function) is to do "o === Object(o)" (an alternative being "o !==
>> null && (typeof o === 'object' || typeof o === 'function')", which is
>> rather long and I have not seen much) which is a bit hacky and not
>> straightforward to read for those who are not familiar with this trick.
>> If an Object.isObject is introduced, I'd be interested in seeing it
>> covering the 8.6 definition.
>> Or maybe introduce another function for this?
>>
>
> That came up too: Object.type(x) would be the new typeof. But it will take
> a while to get adoption, it's not built-in so monkey-patchable etc.
>
>
>>
>>  Use __proto__ in object literals to do a put (assuming that a __proto__
>>> getter/setter was created in Object.prototype) instead of a defineProperty?
>>>  All modes or only nonstrict mode?
>>> Allen: Make such use of __proto__ to be a synonym for <|.  If a <| is
>>> already present, it's an error.
>>> DaveH: __proto__ is ugly.  Don't want it in the language forever.
>>> Waldemar: What about indirect [] expressions that evaluate to
>>> "__proto__"?  In Firefox they evaluate to accesses that climb the prototype
>>> chain and usually reach a magic getter/setter-that-isn't-a-**getter-setter
>>> named __proto__ that sits on Object.prototype.
>>> MarkM: Likes the ability to delete __proto__ setter and thereby prevent
>>> anything in the frame from mutating prototypes.
>>> Waldemar: How do you guard against cross-frame prototype mutations?
>>>
>> With a bit of hope, this is not in use in the web now. One idea would be
>> that no __proto__ is defined on  otherFrame.Object.prototype, and the frame
>> would need to negociate with its parent to get the __proto__ setting
>> capability.
>> This may break the web if currently there is a website which opens
>> iframes which relies on __proto__.
>>
>
> The threat model does not necessarily involve only cross-frame/window
> attacks.
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does private(expr) create a private storage block?

[Herby Vojčík]

Mark S. Miller wrote:

For const classes specifically, my intention is that the "private state"
object is "sealed", i.e., it is non-extensible and all its properties
are non-configurable, but generally writable unless declared otherwise.


Ok, so I present the concerns and then the proposed solutions.

Concern I. An efficient implementation. The private state should be 
allocated with the instance as part of a single allocation, and with no 
undue burden on the garbage collector. (from the class proposal)


(the quote above is also part of this concern)

Concern II. The ability to have private mutable state on publicly frozen 
objects. (from the class proposal)


I went as far as thinking of blending private state with the object 
itself when possible (instances of const classes seemed to be such), but 
this invalidates such optimization (unless freeze would magically left 
private state writable).


Concern III. The ability to use private(foo) on any object and defining 
private stqte lazily, if not present. (me)


Concern IV. No need for 'private foo [= bar];' construct, ability to use 
'private(this).foo = bar | null;' instead having same outcome. (me)


Concern V. We don't want any observable private state object in any 
revised classes proposal. It may be that the current proposal is a bit 
out of date on this, just in terms of terminology and its possible 
misinterpretation (Brendan Eich's reply to this thread)


Solution.
  0. Define prvName as Name.create() for internal use of the private 
keyword inside the class code.
  1. Let 'private foo;' in construct be sugar for 'private(this).foo = 
void 0;'.
  2. Let 'private foo = bar;' in construct be sugar for 
'private(this).foo = bar;'.

  3. Read access to private(foo).bar should
- check if foo[prvName] exists
- if not, return undefined
- if yes, return foo[prvName].bar
  4. Write access to private(foo).bar should
- check if foo[prvName] exists
- if not, try to foo[prvName] = null <| {} (may raise errors)
- do foo[prvName].bar = valueToBeWritten (may raise errors)

The errors in 4. are fine - the former means the object is not 
extensible, so lazy private state cannot be created, but it is 
semantically ok; the latter means the private state itself is not 
extensible or the property itself is read-only.


Why it works for const classes: It creates those properties in private 
state, which are written (declaration is desugared to write) in 
constructor. Then, the instance is frozen/sealed and the private state 
is sealed.


Concern I: OK. Maybe smart compiler can do static analysis of the 
constructor code and create the object prefilled. But I think developer 
can do this as well, hinting nicely to the compiler by code like:


  class Foo {
constructor () {
  ...
  private(this).{
// all or majority of the private data
  }
  ...
}
...
  }

Concern II: Freezing object does not make private state itself frozen. OK.

Concern III: Solved by lazy creation of private state.

Concern IV: Solved by desugaring, making the cases identical, enabled by 
lazy creation.


Concern V: prvName is not visible, private names are not in key list.


--
 Cheers,
 --MarkM


Herby

P.S.: I posted another thread with proposal for shortcut for 
private(this), but it still did not reach the list (I see private(this) 
as non-elegant, too).

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

Re: Does private(expr) create a private storage block?

[Brendan Eich]

Please read the disclaimers: the private(this) syntax is not going to be 
adopted, ever; private name objects and freeze details have been worked 
out separately; the classes proposal is out of date.


/be

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

Re: Does private(expr) create a private storage block?

[Andrea Giammarchi]

I think private specs are a bit weak right now ... or maybe I did not get
them properly ...

   1. what's the expected behavior with mixins ( borrowed method from
   different classes ) ?
   2. what if Object.create(objectWithPrivates, descriptor) ? would
   descriptor methods be able to invoke objectWithPrivates.method() with
   private(this) access in the function body? If yes, would that
   private(this) refer to the objectWithPrivates? This would violate the
   objectWithPrivates private concept, isn't it?
   3. are privates exportable? method() {return private(this)}
   4. are private properties, not private anymore once extracted,
   exportable? method(){return private(this).whatever}
   5. what about a single block in the Class definition such private {c, i
   = 0, storage = {}, whatever} so that these are pre defined in a single
   place and callable across the class scope without requiring usage of
   private(this) but bound to the current context rather than shared across
   all instances?

More may come up soon :-)

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

Re: Jan 18 meeting notes

[Brendan Eich]

David Bruant 
January 19, 2012 1:43 AM

Every time I've been thinking of an issue like this, the solution I've 
found was "whoever runs first wins".


This is not relevant to the example I showed. We have a de-facto 
standard with SpiderMonkey that protects an object from having its 
[[Prototype]] changed once it has cut itself off from Object.prototype. 
Reflecting __proto__ as an accessor breaks this guarantee.


Does this matter? Clearly, it does cross-frame in the web embedding, and 
perhaps there is a narrower solution for that case. But we should 
consider carefully the full impact.


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

Re: Jan 18 meeting notes

[Brendan Eich]

David Bruant 
January 19, 2012 1:15 AM
Le 19/01/2012 02:27, Waldemar Horwat a écrit :

Brendan: Kill typeof null.  Replace it with Ojbect.isObject?

What would be the semantics of this?


It was not obvious but the precedent stems from the strawman that led to 
my proposal to change typeof null:


http://wiki.ecmascript.org/doku.php?id=strawman:object_isobject&rev=1295471005

This week we considered the draft spec:

  Object.isObject = function isObject(value) {
  return typeof value === 'object'&&  value !== null;
  }


to be deficient because a function is also an object, so one might 
rather have


  Object.isObject = function isObject(value) {
  return (typeof value === 'object'&&  value !== null) || typeof value == 
'function';
  }



--
Object.isObject(null); // false
Object.isObject({}); // true
// so far so good :-)
Object.isObject(function(){}) // ?
--
I'd like to advocate "true" for the last case. For now, the best way 
to test if something is of type Object (as defined in ES5.1 - 8.6, so 
including function) is to do "o === Object(o)" (an alternative being 
"o !== null && (typeof o === 'object' || typeof o === 'function')", 
which is rather long and I have not seen much) which is a bit hacky 
and not straightforward to read for those who are not familiar with 
this trick.
If an Object.isObject is introduced, I'd be interested in seeing it 
covering the 8.6 definition.

Or maybe introduce another function for this?


That came up too: Object.type(x) would be the new typeof. But it will 
take a while to get adoption, it's not built-in so monkey-patchable etc.



Use __proto__ in object literals to do a put (assuming that a 
__proto__ getter/setter was created in Object.prototype) instead of a 
defineProperty?  All modes or only nonstrict mode?
Allen: Make such use of __proto__ to be a synonym for <|.  If a <| is 
already present, it's an error.

DaveH: __proto__ is ugly.  Don't want it in the language forever.
Waldemar: What about indirect [] expressions that evaluate to 
"__proto__"?  In Firefox they evaluate to accesses that climb the 
prototype chain and usually reach a magic 
getter/setter-that-isn't-a-getter-setter named __proto__ that sits on 
Object.prototype.
MarkM: Likes the ability to delete __proto__ setter and thereby 
prevent anything in the frame from mutating prototypes.

Waldemar: How do you guard against cross-frame prototype mutations?
With a bit of hope, this is not in use in the web now. One idea would 
be that no __proto__ is defined on  otherFrame.Object.prototype, and 
the frame would need to negociate with its parent to get the __proto__ 
setting capability.
This may break the web if currently there is a website which opens 
iframes which relies on __proto__.


The threat model does not necessarily involve only cross-frame/window 
attacks.


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

Re: Does private(expr) create a private storage block?

[Brendan Eich]

Mark S. Miller 
January 19, 2012 2:38 PM

For const classes specifically, my intention is that the "private 
state" object is "sealed", i.e., it is non-extensible and all its 
properties are non-configurable, but generally writable unless 
declared otherwise.


Hi Mark, just to clarify: we don't want any observable private state 
object in any revised classes proposal. It may be that the current 
proposal is a bit out of date on this, just in terms of terminology and 
its possible misinterpretation.


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

Re: Block lambda is cool, its syntax isn't

[Brendan Eich]

François REMY 
January 19, 2012 12:19 PM
It may be just a personnal taste, but I've to agree the current 
proposal (#() ...) seems very appealing to me. I did not respond to 
your mail proposing to use the Arrow syntax because it seems obscure 
to me. The distinction between "normal" and "fat" arrow is thin, does 
not make sense.


Agreed, and that is another problem plaguing arrow function syntax as 
proposed. But if we rescue it by moving the arrow up front, we may solve 
this problem by dropping fat arrow. "Shorter function syntax" does not 
have to include "shorter .bind(o) syntax".


You either need a function-object (which doesn't have 'this' mapping, 
has expandos) or a local-function (which has 'this' mapping, just need 
to be a [Call] target).


We can't guess and I would not assume a local (nested, you mean?) 
function wants lexical |this| by default, overridden only by callee-base 
|this| when/if the nested function is called as a method. Mark Miller 
showed the problem:


https://mail.mozilla.org/pipermail/es-discuss/2011-November/018186.html

in reply to

https://mail.mozilla.org/pipermail/es-discuss/2011-November/018183.html

If you need the first, you need a traditionnal function since you need 
something not-frozen that can be added to objects as a property at a 
later time. If you want 'this' mapping, you need something that only 
makes sense in a local context.


You mean a block-lambda? I agree.


Additionnaly, the arrow syntax is illogical. You usually say "I want a 
function of (X,Y) which returns X+Y" or "I want to transform X in 
X.toString", not "From X, I want to get X.toString()".


I'm not sure what you mean here by "illogical" and your verbal 
expansions -- are you saying the arrow should come in between params and 
body? Yes, that is nicer and Jeremy Ashkenas followed that design (used 
in other languages of course) for that reason. But it makes for grammar 
trouble for two reasons:


1. (params) looks like a comma expression. We can parse it as such and 
then validate it using "supplemental syntax" as for destructuring, but 
it is a bit future-hostile.


2. If we want an expression body alternate syntax that prefers object 
literals over body blocks, we have to resolve this conflict:


http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal

Doing so is even more future-hostile in light of the new object literal 
extensions in ES6.


Freezing a local function seems as acceptable to me as it seemed to 
others. A LF should only be used in a controlled context where the 
function itself is just used as a function, not an object. But if it's 
not acceptable to other members, I'm not against a @(x) syntax that 
does not offer frozen functions (but I think it's a missed 
optimization opportunity).


Again, @ is wanted for private names -- all the few unused ASCII 
punctuators are wanted. Why are you insisting on @ here? It's not 
particularly associated with functions in other languages, or suggestive 
of functions.


In my view of the thing, a local function should be used as a function 
in the mathematical sense of the term: you give a parameter, it 
returns its image by the function.


JS practice varies wildly. No developer consensus on this point.


The cases we are trying to solve:

   var inc=#(x) x+1;

   array.map(#(x) x.toString());

   array.filter(#(x) isValid(x));

   array.map(#(x) {
   while(x.previousSibling) x=x.previousSibling;
   return x;
   });


This case is not like the one you showed earlier, and not so clearly bad 
for block-lambda. There is only one return, it's at the bottom, so 
completion value as implicit return value in a block-lambda wins:



   array.map({ |x|
   while(x.previousSibling) x=x.previousSibling;
   x;
   });


It's not a requirement either way, of course.


For example, I don't see this as a good use-case of a LocalFunction :

   ...
   refreshLayout: function(e) {
   ...
   requestAnimationFrame(#(e) this.refreshLayout(e));
   }
   ...

It should be a block lambda instead, because it's meant to 'continue' 
the current function in a sort of async while(true) loop.


Oh but here is a case where you advocate a block-lamdba for an "async 
callback". IIRC earlier you wrote that block-lambdas should be used for 
sync callbacks. I may have misread you though.


I dont believe there's a hard and fast rule. Of course, the block-lambda 
cannot break/continue/return if the enclosing function activation is no 
more.


   ...
   refreshLayout: function(e) {
   ...
   requestAnimationFrame({|e| this.refreshLayout(e) });
   }
   ...

For all of the use cases where a "mathematical function" is requied, 
you just need some valid [Call]-able item. You will never add expandos 
on an function you don't know (ie that you received as a parameter).


No, but local functions are decorated with expandos in their local scope.

You'll wrap it before, if you really need that. If you

Re: Block lambda is cool, its syntax isn't

[Brendan Eich]

Now you are forgetting the argument that TCP-conforming block-lambdas 
*should* look quite different from ...(params) {body} functions. This 
implies that shorter function syntax ought to follow the (params) {body} 
plan.


/be


Herby Vojčík 
January 19, 2012 11:40 AM
Brendan Eich wrote:

Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.


First, #(params) { body } was proposed by Arv and Alex:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.


Well, if #(x, y) {x+y} is not good because of # is used for freezing 
and freezing is not good (it is not, metadata is good argument for 
that), and if something-like-lambda-block is ok, some variation of 
lambda-block could be the shorter replacement for functions. These 
come to mind:


  {*a, b* a+b}
  {/a, b/ a+b}
  {^a, b^ a+b}
  {%a, b% a+b}

and there is still more infix operators...

maybe even {`a, b` a+b} if it does not create conflict in this context.


/be


Herby

Brendan Eich 
January 19, 2012 11:27 AM
Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If 
you want anything else, you can use a traditional function. Then the 
above syntax as the only function shorthand would be OK.



First, #(params) { body } was proposed by Arv and Alex:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

Arv and Alex feel strongly that the shorter function syntax (anything 
shortening 'function' syntax) must not freeze by default.


There was lack of clarity about whether completion value as implicit 
return value was part of the proposal. If so, controvery, since there 
is a completion value leak hazard. TC39 seems to agree the solution 
there is something with different look & feel, such as block-lambdas.


But, making a one-char grawlix shorthand for 'function' while still 
requiring 'return' is not considered enough of a shorthand. A possible 
cure here is to support an alternative body syntax: #(params) expr. 
However, this inverts precedence if done naively. It also runs into 
trouble trying to prefer an object literal over a block statement. 
I've worked on both of these in the context of


http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

This superseded shorter_function_syntax, but ran into grammatical 
issues that have vexed it.


But notice that throughout this, no one advancing a proposal advocated 
freezing by default. JS developers use function objects as mutable 
objects. Not just to set .prototype, also to decorate with ad-hoc and 
meta-data properties. Freezing is not wanted by default.


I agree that for block-lambdas it's easier to say "freeze by default". 
For merely "shorter function syntax", no. Functions are mutable 
objects by default in JS. This matters for minifiers, which may not be 
able to see all the mutations but would love to use shorter syntax for 
'function' syntax, blindly.


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

Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If 
you want anything else, you can use a traditional function. Then the 
above syntax as the only function shorthand would be OK.


--
Dr. Axel Rauschmayer
a...@rauschma.de 

home: rauschma.de 
twitter: twitter.com/rauschma 
blog: 2ality.com 

Brendan Eich 
January 19, 2012 9:25 AM

I'm not sure what you mean. I proposed this a while ago ("Harmony of 
My Dreams") but we don't want frozen by design, and without the # the 
result is ambiguous without restricted productions, and hazardous on 
that account.


The idea that any grawlixy preifx will do is false. Hash is wanted for 
consistent freeze/seal prefixing. Arrow is better and putting it at 
the front solves the grammar problems with arrow function syntax as 
current drafted.


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

Axel Rauschmayer 
January 19, 2012 12:06 AM


Couldn’t one always freeze such a function shorthand and then get 
syntax such as:


 #(x, y) { x + y }

--
Dr. Axel Rauschmayer
a...@rauschma.de 

home: rauschma.de 
twitter: twitter.com/rauschma 
blog: 2alit

Re: Does private(expr) create a private storage block?

[Mark S. Miller]

On Thu, Jan 19, 2012 at 1:00 PM, Herby Vojčík  wrote:

> Hello,
>
> Mark S. Miller wrote:
>
>> ... I don't have strong feelings about this for non-const
>>
>> classes. For const classes, I think privates should always be declared
>> in the constructor. I would like to be able to always allocate instances
>> of const classes of fixed "shape", i.e., non-configurable /
>> non-extensible, so that users don't have to worry about whether they've
>> enabled the resulting optimizations or whether they have uncaught
>> spelling errors.
>>
>
> It is written in class proposal:
>
> - An efficient implementation. The private state should be allocated with
> the instance as part of a single allocation, and with no undue burden on
> the garbage collector.
> - The ability to have private mutable state on publicly frozen objects.
>
> Now it is the question, what does it say about "fixed shape". Does "fixed
> shape" mean no private can be added / deleted, but private properties
> themselves can be mutated? Or is it the weaker "the private space must be
> created and is not removable (in frozen object), but it is itself
> extensible and private properties are configurable and writable"?
>
>
>  For consistency, perhaps we should make similar requirements for
>> privates of non-const classes, but this isn't clear. If you have some
>> arguments one way or another, please post. Thanks.
>>
>
> I have more thoughts on this, even the proposal how to make it work
> dynamically for non-const classes and "fixed" in const classes, but the
> answer to previous question seems important.
>
> I presume the answer is "the latter", since "with no undue burden on the
> garbage collector" could be read as "if possible, blended in single
> object". But I would like to hear from you.
>


For const classes specifically, my intention is that the "private state"
object is "sealed", i.e., it is non-extensible and all its properties are
non-configurable, but generally writable unless declared otherwise.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[François REMY]

Yet they are cases where a block lambda isn’t suited and where a ‘classic’ 
function is just too long to type (and would hurt performance as well). Look 
back in the thread for a sample. (Mainly: cases involving a ‘return’ in a loop 
or in a nested statement can’t be solved well using block-lambda).

Block lambda is not the solution since it wasn’t written to solve the cases 
where we traditionnaly use a 'local function’, but to solve new use-cases where 
we want our function to continue to run inside a function structure, or 
asynchronously. The old cases where we use “function() { ... { ... return; } 
... }” are not covered properly by block lambda, nor are intended to. 

From: Axel Rauschmayer 
Sent: Thursday, January 19, 2012 10:14 PM
To: Brendan Eich 
Cc: Andreas Rossberg ; François REMY ; Oliver Hunt ; es-discuss Steen 
Subject: Re: Block lambda is cool, its syntax isn't
FTR: With block lambdas and object literal extensions, I wouldn’t want/need a 
function shorthand. I thought I had seen an opportunity for a more compact 
syntax (if and only if function shorthands are needed), but was wrong. Sorry.

Suggestion: a community-edited page where we collect the rejected syntaxes (=> 
less running in circles) – simply copying emails (such as yours below) there 
would probably suffice.

On Jan 19, 2012, at 20:27 , Brendan Eich wrote:


  Axel Rauschmayer 
  January 19, 2012 9:31 AM

  Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you 
want anything else, you can use a traditional function. Then the above syntax 
as the only function shorthand would be OK.


  First, #(params) { body } was proposed by Arv and Alex:

  http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

  Arv and Alex feel strongly that the shorter function syntax (anything 
shortening 'function' syntax) must not freeze by default.

  There was lack of clarity about whether completion value as implicit return 
value was part of the proposal. If so, controvery, since there is a completion 
value leak hazard. TC39 seems to agree the solution there is something with 
different look & feel, such as block-lambdas.

  But, making a one-char grawlix shorthand for 'function' while still requiring 
'return' is not considered enough of a shorthand. A possible cure here is to 
support an alternative body syntax: #(params) expr. However, this inverts 
precedence if done naively. It also runs into trouble trying to prefer an 
object literal over a block statement. I've worked on both of these in the 
context of

  http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

  This superseded shorter_function_syntax, but ran into grammatical issues that 
have vexed it.

  But notice that throughout this, no one advancing a proposal advocated 
freezing by default. JS developers use function objects as mutable objects. Not 
just to set .prototype, also to decorate with ad-hoc and meta-data properties. 
Freezing is not wanted by default.

  I agree that for block-lambdas it's easier to say "freeze by default". For 
merely "shorter function syntax", no. Functions are mutable objects by default 
in JS. This matters for minifiers, which may not be able to see all the 
mutations but would love to use shorter syntax for 'function' syntax, blindly.

  /be



-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Axel Rauschmayer]

FTR: With block lambdas and object literal extensions, I wouldn’t want/need a 
function shorthand. I thought I had seen an opportunity for a more compact 
syntax (if and only if function shorthands are needed), but was wrong. Sorry.

Suggestion: a community-edited page where we collect the rejected syntaxes (=> 
less running in circles) – simply copying emails (such as yours below) there 
would probably suffice.

On Jan 19, 2012, at 20:27 , Brendan Eich wrote:

> Axel Rauschmayer 
> January 19, 2012 9:31 AM
> 
> Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you 
> want anything else, you can use a traditional function. Then the above syntax 
> as the only function shorthand would be OK.
> 
> 
> First, #(params) { body } was proposed by Arv and Alex:
> 
> http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
> 
> Arv and Alex feel strongly that the shorter function syntax (anything 
> shortening 'function' syntax) must not freeze by default.
> 
> There was lack of clarity about whether completion value as implicit return 
> value was part of the proposal. If so, controvery, since there is a 
> completion value leak hazard. TC39 seems to agree the solution there is 
> something with different look & feel, such as block-lambdas.
> 
> But, making a one-char grawlix shorthand for 'function' while still requiring 
> 'return' is not considered enough of a shorthand. A possible cure here is to 
> support an alternative body syntax: #(params) expr. However, this inverts 
> precedence if done naively. It also runs into trouble trying to prefer an 
> object literal over a block statement. I've worked on both of these in the 
> context of
> 
> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
> 
> This superseded shorter_function_syntax, but ran into grammatical issues that 
> have vexed it.
> 
> But notice that throughout this, no one advancing a proposal advocated 
> freezing by default. JS developers use function objects as mutable objects. 
> Not just to set .prototype, also to decorate with ad-hoc and meta-data 
> properties. Freezing is not wanted by default.
> 
> I agree that for block-lambdas it's easier to say "freeze by default". For 
> merely "shorter function syntax", no. Functions are mutable objects by 
> default in JS. This matters for minifiers, which may not be able to see all 
> the mutations but would love to use shorter syntax for 'function' syntax, 
> blindly.
> 
> /be
> 

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: Does private(expr) create a private storage block?

[Herby Vojčík]

Hello,

Mark S. Miller wrote:

... I don't have strong feelings about this for non-const
classes. For const classes, I think privates should always be declared
in the constructor. I would like to be able to always allocate instances
of const classes of fixed "shape", i.e., non-configurable /
non-extensible, so that users don't have to worry about whether they've
enabled the resulting optimizations or whether they have uncaught
spelling errors.


It is written in class proposal:

- An efficient implementation. The private state should be allocated 
with the instance as part of a single allocation, and with no undue 
burden on the garbage collector.

- The ability to have private mutable state on publicly frozen objects.

Now it is the question, what does it say about "fixed shape". Does 
"fixed shape" mean no private can be added / deleted, but private 
properties themselves can be mutated? Or is it the weaker "the private 
space must be created and is not removable (in frozen object), but it is 
itself extensible and private properties are configurable and writable"?



For consistency, perhaps we should make similar requirements for
privates of non-const classes, but this isn't clear. If you have some
arguments one way or another, please post. Thanks.


I have more thoughts on this, even the proposal how to make it work 
dynamically for non-const classes and "fixed" in const classes, but the 
answer to previous question seems important.


I presume the answer is "the latter", since "with no undue burden on the 
garbage collector" could be read as "if possible, blended in single 
object". But I would like to hear from you.



On Mon, Jan 9, 2012 at 8:33 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote:

Hello,

the current class proposal (as I read it) specifies that the private
block is created by first 'private foo[ = "bar"];' in the
constructor. The question is, what is constructor does not contain
any private declarations, but uses private, like this:

class Coutner {
  constructor () {
   this.reset();
  }

  increment () {
   private(this).c++;
  }

  reset () {
   private(this).c = 0;
  }

  get count () {
   return private(this).c;
  }
}

The reset method is part of the API. Conveniently, it resets the
state of the object to the initial state, so constructor is calling it.
The question is: does private(this) create the private storage block
in this case?

Herby

--
 Cheers,
 --MarkM

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

Re: Block lambda is cool, its syntax isn't

[François REMY]

It may be just a personnal taste, but I've to agree the current proposal 
(#() ...) seems very appealing to me. I did not respond to your mail 
proposing to use the Arrow syntax because it seems obscure to me. The 
distinction between "normal" and "fat" arrow is thin, does not make sense. 
You either need a function-object (which doesn't have 'this' mapping, has 
expandos) or a local-function (which has 'this' mapping, just need to be a 
[Call] target). If you need the first, you need a traditionnal function 
since you need something not-frozen that can be added to objects as a 
property at a later time. If you want 'this' mapping, you need something 
that only makes sense in a local context.


Additionnaly, the arrow syntax is illogical. You usually say "I want a 
function of (X,Y) which returns X+Y" or "I want to transform X in 
X.toString", not "From X, I want to get X.toString()".


Freezing a local function seems as acceptable to me as it seemed to others. 
A LF should only be used in a controlled context where the function itself 
is just used as a function, not an object. But if it's not acceptable to 
other members, I'm not against a @(x) syntax that does not offer frozen 
functions (but I think it's a missed optimization opportunity). The point 
about Conditionnal Compiling in IE is not valid anymore since Microsoft has 
deleted HTML Conditionnal Comments because they were not standards (even if 
they were used a lot), so I don't think the obscure and fewly used JScript 
CC are meant to stay, especially if it hurts another proposal.


In my view of the thing, a local function should be used as a function in 
the mathematical sense of the term: you give a parameter, it returns its 
image by the function.


The cases we are trying to solve:

   var inc=#(x) x+1;

   array.map(#(x) x.toString());

   array.filter(#(x) isValid(x));

   array.map(#(x) {
   while(x.previousSibling) x=x.previousSibling;
   return x;
   });

For example, I don't see this as a good use-case of a LocalFunction :

   ...
   refreshLayout: function(e) {
   ...
   requestAnimationFrame(#(e) this.refreshLayout(e));
   }
   ...

It should be a block lambda instead, because it's meant to 'continue' the 
current function in a sort of async while(true) loop.


   ...
   refreshLayout: function(e) {
   ...
   requestAnimationFrame({|e| this.refreshLayout(e) });
   }
   ...

For all of the use cases where a "mathematical function" is requied, you 
just need some valid [Call]-able item. You will never add expandos on an 
function you don't know (ie that you received as a parameter). You'll wrap 
it before, if you really need that. If you want the full flexibility of a 
function-as-an-object, it means you need a 'true function'; LF are not meant 
to replace functions in the long run, they are made to serve the case where 
you want a short, action-related, contextual function. That means 'this' 
binding, if needed, just like it's in languages like dotNET.


However, I would like to hear more about the specific reasons that led Arv 
and Alex think a LF should not be frozen.


Regards,
François



PS: The synax I speak about for LocalFunctions would be:

:
   '#('  ')' 
   or
   '#('  ') {' * '}'

They would be 'bound-this' if there's a 'this' in their body, but can be 
left unbounded if there's no since it has no visible effet. If they don't 
reference variables of a scope, they should not use reference scope and may 
be reused accross function calls.





-Message d'origine- 
From: Brendan Eich

Sent: Thursday, January 19, 2012 8:27 PM
To: Axel Rauschmayer ; Andreas Rossberg
Cc: François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't

Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.


First, #(params) { body } was proposed by Arv and Alex:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.

There was lack of clarity about whether completion value as implicit
return value was part of the proposal. If so, controvery, since there is
a completion value leak hazard. TC39 seems to agree the solution there
is something with different look & feel, such as block-lambdas.

But, making a one-char grawlix shorthand for 'function' while still
requiring 'return' is not considered enough of a shorthand. A possible
cure here is to support an alternative body syntax: #(params) expr.
However, this inverts precedence if done naively. It also runs into
trouble trying to prefer an object literal over a block statement. I've
worked on both of these in the context of

http://wiki.ecmascript.org/doku.php?id=strawman:arrow_fun

Re: Block lambda is cool, its syntax isn't

[Herby Vojčík]

Brendan Eich wrote:

Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If
you want anything else, you can use a traditional function. Then the
above syntax as the only function shorthand would be OK.


First, #(params) { body } was proposed by Arv and Alex:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.


Well, if #(x, y) {x+y} is not good because of # is used for freezing and 
freezing is not good (it is not, metadata is good argument for that), 
and if something-like-lambda-block is ok, some variation of lambda-block 
could be the shorter replacement for functions. These come to mind:


  {*a, b* a+b}
  {/a, b/ a+b}
  {^a, b^ a+b}
  {%a, b% a+b}

and there is still more infix operators...

maybe even {`a, b` a+b} if it does not create conflict in this context.


/be


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

Re: Block lambda is cool, its syntax isn't

[Brendan Eich]

Axel Rauschmayer 
January 19, 2012 9:31 AM

Rationale: wouldn’t freezing by default be OK for 98% of the cases? If 
you want anything else, you can use a traditional function. Then the 
above syntax as the only function shorthand would be OK.



First, #(params) { body } was proposed by Arv and Alex:

http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax

Arv and Alex feel strongly that the shorter function syntax (anything 
shortening 'function' syntax) must not freeze by default.


There was lack of clarity about whether completion value as implicit 
return value was part of the proposal. If so, controvery, since there is 
a completion value leak hazard. TC39 seems to agree the solution there 
is something with different look & feel, such as block-lambdas.


But, making a one-char grawlix shorthand for 'function' while still 
requiring 'return' is not considered enough of a shorthand. A possible 
cure here is to support an alternative body syntax: #(params) expr. 
However, this inverts precedence if done naively. It also runs into 
trouble trying to prefer an object literal over a block statement. I've 
worked on both of these in the context of


http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

This superseded shorter_function_syntax, but ran into grammatical issues 
that have vexed it.


But notice that throughout this, no one advancing a proposal advocated 
freezing by default. JS developers use function objects as mutable 
objects. Not just to set .prototype, also to decorate with ad-hoc and 
meta-data properties. Freezing is not wanted by default.


I agree that for block-lambdas it's easier to say "freeze by default". 
For merely "shorter function syntax", no. Functions are mutable objects 
by default in JS. This matters for minifiers, which may not be able to 
see all the mutations but would love to use shorter syntax for 
'function' syntax, blindly.


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

Re: A different semantics for WeakMap#get default value

[Jason Orendorff]

On Thu, Jan 19, 2012 at 12:51 AM, Mark S. Miller  wrote:
> Hi Jason, I like the idea that the Python defaultdict seems almost to be,
> which I'll call an InfiniteMap. For JS, the following InfiniteMap actually
> obeys the Map contract while implementing a Map with an infinite number of
> key-value mappings. It's initial state is total -- it provides a mapping for
> every key, and so, in this initial state, infMap.has(key) would always
> return true. It does this by using the lazyFactory function as needed to
> make the infinite population of values initially associated with each of the
> infinite population of keys.

That was my first impression too, during the 2006 discussion when
defaultdict was being designed. The issue was raised. But Guido
intentionally made defaultdict inconsistent with the Mapping contract,
on the grounds that being able to access the actual data was much more
important than the invariant. He was right. I think InfiniteMap would
be unsuitable for most defaultdict use cases. Consider:

# Python
def mostFrequentWord(words):
counts = defaultdict(lambda: 0)
for word in words:
counts[word] += 1
return max(counts.keys(), key=lambda w: counts[w])

// ES with InfiniteMap
function mostFrequentWord(words) {
var counts = InfiniteMap(function () { return 0; });
for (var word of words)
counts.set(word, counts.get(word) + 1);
//...now what?
}

Defaulting is useful when building a data structure. But data
structures also need to be queried, aggregated, and updated, and at
that point the program usually needs to see the data as it is—an
impenetrable illusion of infinity is counterproductive.

Anyway, note that David's motivating use cases are *not* cases where
he needs to pass the Map to Map-consuming library code and needs an
object that satisfies Map's contract. Rather, Map is being used as a
concrete type (as usual for core types) and its API is just clumsy for
this particular purpose. That need can be addressed directly.

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

Re: Block lambda is cool, its syntax isn't

[Herby Vojčík]

Andreas Rossberg wrote:

On 19 January 2012 18:31, Axel Rauschmayer  wrote:

Rationale: wouldn’t freezing by default be OK for 98% of the cases?


Especially since the cases where you care most about short syntax are
throw-away functions.

The only sane reason I have seen for mutating a function is to set its
prototype property. But who wants to write constructors as short
lambdas?  Another use case is modelling C-style static variables as
properties, but you cannot do that with an anonymous function anyway
(I also don't regard it as particularly sane, but who am I to judge).


I'd say +1 for frozen shortcut functions. I also don't see the use case 
where mutating _the_function_ itself would be needed in such cases. It 
seems to me it is ok for big percentage of uses. If you need mutable 
one, use function.


Only fearful factor is when frozen one is used and in the runtime 
mutation is needed for something... but I could not find such use... 
wrapping such function is still possible, that is probably most 
possibility you need in runtime when monkey-patching or something.


Correct me if I am wrong.


/Andreas

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

Re: Block lambda is cool, its syntax isn't

[Andreas Rossberg]

On 19 January 2012 18:31, Axel Rauschmayer  wrote:
> Rationale: wouldn’t freezing by default be OK for 98% of the cases?

Especially since the cases where you care most about short syntax are
throw-away functions.

The only sane reason I have seen for mutating a function is to set its
prototype property. But who wants to write constructors as short
lambdas?  Another use case is modelling C-style static variables as
properties, but you cannot do that with an anonymous function anyway
(I also don't regard it as particularly sane, but who am I to judge).

Are there other relevant use cases?

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

Re: Globalisation feedback

[Norbert Lindenberg]

But time zones other than UTC and the "host environment's current time zone" 
are not supported. This limitation exists in version 1 of the API spec because 
one implementation currently doesn't support other time zones. We hope that in 
the next version this limitation can be removed and all IANA time zone names be 
supported.

The specification references Unicode Technical Standard 35 - that's not a 
version number, but the number of the document within the set of Unicode 
Technical Reports:
http://www.unicode.org/reports/

Norbert


On Jan 19, 2012, at 9:06 , Nebojša Ćirić wrote:

> We do support UTC and local timezone (whatever it may be). The actual 
> representation of the time zone will differ among platforms (GMT-7, Los 
> Angeles/Pacific...).
> 
> 18. јануар 2012. 22.16, Oliver Hunt  је написао/ла:
> Unfortunately I'm not feeling well so I doubt I'll make tomorrows meeting.
> 
> Here's some feedback on the globalisation API, from people who are more 
> knowledgeable in these matters than I (although not JS experts :D ).
> 
> * Near the bottom of page 31 [labeled page 25], there is a small typo:  
> "[[ocaleData]]"
> 
> * It seems to be bailing on requiring time zone support, other than for UTC.  
> So, no formatting of dates into local times?  (except a provided by 
> implementation-specific extensions to this standard, perhaps)
> 
> There was some other stuff but it may have been due to confusion over whether 
> UTS v35 or v36 was intended (I assume this means more to others than to me).  
> Once I've got it clarified I'll pass it on.
> 
> --Oliver

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

Re: Block lambda is cool, its syntax isn't

[Axel Rauschmayer]

>> Couldn’t one always freeze such a function shorthand and then get syntax 
>> such as:
>> 
>> #(x, y) { x + y }
> 
> I'm not sure what you mean. I proposed this a while ago ("Harmony of My 
> Dreams") but we don't want frozen by design, and without the # the result is 
> ambiguous without restricted productions, and hazardous on that account.
> 
> The idea that any grawlixy preifx will do is false. Hash is wanted for 
> consistent freeze/seal prefixing. Arrow is better and putting it at the front 
> solves the grammar problems with arrow function syntax as current drafted.


Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you want 
anything else, you can use a traditional function. Then the above syntax as the 
only function shorthand would be OK.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: A different semantics for WeakMap#get default value

[Mark S. Miller]

I will try to write a complete proposal and settle it at the March meeting.
I'll propose today that this be on the March agenda. I'll keep it extremely
small.

On Thu, Jan 19, 2012 at 5:36 AM, Andreas Rossberg wrote:

> On 19 January 2012 09:00, Andrea Giammarchi 
> wrote:
> > Out of curiosity, Chrome experimental flag does not support get(key,
> > defaultValue) but get(key) only ... is this something missing or Map and
> > WeakMap will never support officially the second get() argument?
>
> Chrome/V8 simply implements what the current proposals say:
>
> http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
> http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps
>
> Of course, we are happy to adapt if the proposals get extended along
> the lines you mention.
>
> /Andreas
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Brendan Eich]

Axel Rauschmayer 
January 19, 2012 12:06 AM


Couldn’t one always freeze such a function shorthand and then get 
syntax such as:


 #(x, y) { x + y }


I'm not sure what you mean. I proposed this a while ago ("Harmony of My 
Dreams") but we don't want frozen by design, and without the # the 
result is ambiguous without restricted productions, and hazardous on 
that account.


The idea that any grawlixy preifx will do is false. Hash is wanted for 
consistent freeze/seal prefixing. Arrow is better and putting it at the 
front solves the grammar problems with arrow function syntax as current 
drafted.


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

Re: A different semantics for WeakMap#get default value

[Mark S. Miller]

On Thu, Jan 19, 2012 at 12:44 AM, Andreas Rossberg wrote:

> On 19 January 2012 07:51, Mark S. Miller  wrote:
> >
> > Because an instance of InfiniteMap conforms to the full Map contract
> (given
> > that baseMap does and is not otherwise used), we have full Liskov
> > substitutability -- you can validly pass an InfiniteMap to an abstraction
> > expecting a Map.
>
> PS: Won't the "full Map contract" eventually contain iterators, too?
> An infinite map cannot sensibly support those.
>
>
Depends what you mean by "sensibly". I see nothing at
http://wiki.ecmascript.org/doku.php?id=harmony:iterators that implies that
iterators must or even should terminate. And infinite iterators (in general
though not here) are clearly useful.

However, I agree that doing an infinite iteration over an InfiniteMap is
unlikely to be useful. For example, the contract can almost be trivially
and uselessly satisfied by having the InfiniteMap return the following
"items" (key-value pair) iterator:

{ next: function() { return [{}, lazyFactory()]; } }

Since each of these keys are fresh, we know we don't need to consult the
baseMap for an overriding mapping. Since there are an infinite number of
such keys, we know they'll never run out, so we can indefinitely postpone
ever needing to return a meaningful mapping. However the "almost" qualifier
above is because, to be correct, the iterator would have to store the new
useless associations in the baseMap before returning them -- making this
technique even more useless.

Infinities are indeed weird.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A different semantics for WeakMap#get default value

[Andrea Giammarchi]

On Thu, Jan 19, 2012 at 6:11 PM, Mark S. Miller  wrote:
>
>
> That's not quite true in the collection I posted, since an InfiniteMap is
> only *initially* total. It still emulates deletes by using tombstones to
> poke holes into its initially universal domain. When doing a get at a
> deleted key, the defaultValue would come into effect.
>

got it, my concern was mainly about the very first case where defaultValue
is not even considered and we have two completely different behaviors if we
get before or after a key has been set ... no way to use the lazyFactory(key,
defaultValue) { ... do stuff and return defaultValue }, if necessary, in
order to be able to instantly set that default ( I just find weird this
"need to delete first, then get default after" )

Hope you got what I mean

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

Re: Jan 18 meeting notes

[Brendan Eich]

Herby Vojčík 
January 19, 2012 6:32 AM


What about obj.{ ... } literal extension? It is not mentioned, and 
afaict is unproblematic, too.


Thanks, we did miss that one -- it was among the object literal 
extensions not at the top level of harmony:proposals.


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

Re: A different semantics for WeakMap#get default value

[Mark S. Miller]

On Thu, Jan 19, 2012 at 12:00 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> On Thu, Jan 19, 2012 at 7:51 AM, Mark S. Miller wrote:
>
>>
>> Everyone on this thread, is there any need expressed in this thread that
>> is not satisfied by InfiniteMap?
>>
>>
>
> I would say for "notification purpose"
>
> result = lazyFactory(key, defaultValue);
>
> would be more appropriate
>

Hi Andrea, as I just mentioned in my reply to Andreas, I think this is a
good suggestion. However,




> otherwise the defaultValue looses completely its meaning the moment "key"
> is not there due the first if.
>

That's not quite true in the collection I posted, since an InfiniteMap is
only *initially* total. It still emulates deletes by using tombstones to
poke holes into its initially universal domain. When doing a get at a
deleted key, the defaultValue would come into effect.



>
> Out of curiosity, Chrome experimental flag does not support get(key,
> defaultValue) but get(key) only ... is this something missing or Map and
> WeakMap will never support officially the second get() argument?
>
> br
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A different semantics for WeakMap#get default value

[Mark S. Miller]

On Wed, Jan 18, 2012 at 11:37 PM, Andreas Rossberg wrote:

> On 19 January 2012 07:51, Mark S. Miller  wrote:
> > Everyone on this thread, is there any need expressed in this thread that
> is
> > not satisfied by InfiniteMap?
>
> Looks good, except that I don't understand why you want a lazyFactory
> function instead of a simple initialValue -- if you recommend
> lazyFactory having no observable side effect, then (with no arguments)
> it will be a constant function, and you could as well use a plain
> value.
>
> On the other hand, a function would be useful if it also got the key
> as an argument, so that it can manufacture values in a key-dependent
> manner.


I think providing the key, or the key and defaultValue as Andrea suggests
is a fine idea. However, even without these, the answer to your question is
"fresh mutable state" as in

function lazyFactory() { return Set(); }
or similarly
function lazyFactory() { return []; }
etc

This addresses the only concrete use cases I've seen mentioned in this
thread -- using nested single-key single-valued collections to emulate
either

a) multi-valued collections, i.e., MultiMaps, as single-valued collections
from keys to sets of values, or

b) multi-keyed collections, i.e., a two dimensional map, as a map from a
first key to a collection mapping from a second key (array index) to a
value.



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalisation feedback

[Nebojša Ćirić]

We do support UTC and local timezone (whatever it may be). The actual
representation of the time zone will differ among platforms (GMT-7, Los
Angeles/Pacific...).

18. јануар 2012. 22.16, Oliver Hunt  је написао/ла:

> Unfortunately I'm not feeling well so I doubt I'll make tomorrows meeting.
>
> Here's some feedback on the globalisation API, from people who are more
> knowledgeable in these matters than I (although not JS experts :D ).
>
> * Near the bottom of page 31 [labeled page 25], there is a small typo:
>  "[[ocaleData]]"
>
> * It seems to be bailing on requiring time zone support, other than for
> UTC.  So, no formatting of dates into local times?  (except a provided by
> implementation-specific extensions to this standard, perhaps)
>
> There was some other stuff but it may have been due to confusion over
> whether UTS v35 or v36 was intended (I assume this means more to others
> than to me).  Once I've got it clarified I'll pass it on.
>
> --Oliver
>
> On Jan 18, 2012, at 12:11 PM, Norbert Lindenberg wrote:
>
> > We use es-discuss@, with "globalization" or "internationalization" as
> part of the subject line to help us pick out internationalization-related
> messages from the daily flood.
> >
> > Looking forward to your feedback,
> > Norbert
> >
> >
> > On Jan 18, 2012, at 11:39 , Oliver Hunt wrote:
> >
> >> Ah, where is the new location?  Also I have some feedback on the i18n
> stuff which i don't understand (not being an i18n person, but it's from
> people who do) is there a separate list for that?
> >>
> >> --Oliver
> >>
> >> On Jan 18, 2012, at 10:22 AM, Nebojša Ćirić wrote:
> >>
> >>> Some probably missed Sunnyvale -> Santa Clara switch.
> >>>
> >>> Norbert and I will be in tomorrow for i18n status/discussion.
> >>>
> >>> 18. јануар 2012. 10.18, Waldemar Horwat  је
> написао/ла:
> >>> We're starting the TC39 meeting. Most of the representatives are still
> MIA.
> >>>
> >>>Waldemar
> >>>
> >>>
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Nebojša Ćirić
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
>
>


-- 
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Jan 18 meeting notes

[Herby Vojčík]

Waldemar Horwat wrote:

Which ES6 features can be backported into non-strict mode?
(blank: no significant issues;
  ?: possible issues;
  x: semantics conflict with de facto web)

? let  (syntax issues)
x const  (divergent semantics)
x function in block  (divergent semantics)
? destructuring  (syntactic conflict with array lookup)
   parameter default values
   rest parameters
   spread
x tail calls  (because of Function.caller)
   direct proxies
   simple maps and sets
   weak maps
   is / isnt (egal)
   iterators
? generators  (interaction with scoping issues and yield keyword)
   generator expressions
   comprehensions
   private names
   quasi-literals
   pragmas  (controversial)
? completion reform  (Brendan: might be able to get away with it without
breaking the web, but we don't know yet)
x typeof null  (Erik: It breaks the web)
   class
   super
n/a modules
   methods in object literals
<|
   ({[computed_name]: value})  (MarkM: what should happen with duplicate
names in nonstrict mode?)


What about obj.{ ... } literal extension? It is not mentioned, and 
afaict is unproblematic, too.


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

Re: A different semantics for WeakMap#get default value

[Andreas Rossberg]

On 19 January 2012 09:00, Andrea Giammarchi  wrote:
> Out of curiosity, Chrome experimental flag does not support get(key,
> defaultValue) but get(key) only ... is this something missing or Map and
> WeakMap will never support officially the second get() argument?

Chrome/V8 simply implements what the current proposals say:

http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps

Of course, we are happy to adapt if the proposals get extended along
the lines you mention.

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

Re: Jan 18 meeting notes

[David Bruant]

Le 19/01/2012 02:27, Waldemar Horwat a écrit :
Waldemar: Opposed to making __proto__ mutate prototypes other than at 
object construction.  This is getting insanely complex.
Just found a minute ago [1]. At line 50, __proto__ is used. Here, the 
notion of "object construction" is subtle (which is probably one of the 
cases considered to say "This is getting insanely complex"). It has to  
be noted that this is node.js code, which runs on an ES5-capable 
environment.
In this particular case, since no runner is created in the file, a 
standard equivalent to "Runner.prototype.__proto__ = 
EventEmitter.prototype;"

could be:
"Runner.prototype = Object.create(EventEmitter.prototype);"

David

[1] https://github.com/visionmedia/mocha/blob/master/lib/runner.js#L34
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Jan 18 meeting notes

[David Bruant]

Le 19/01/2012 06:44, Brendan Eich a écrit :
Use __proto__ in object literals to do a put (assuming that a 
__proto__ getter/setter was created in Object.prototype) instead of a 
defineProperty?  All modes or only nonstrict mode?
Allen: Make such use of __proto__ to be a synonym for <|.  If a <| is 
already present, it's an error.

DaveH: __proto__ is ugly.  Don't want it in the language forever.
Waldemar: What about indirect [] expressions that evaluate to 
"__proto__"?  In Firefox they evaluate to accesses that climb the 
prototype chain and usually reach a magic 
getter/setter-that-isn't-a-getter-setter named __proto__ that sits on 
Object.prototype.
MarkM: Likes the ability to delete __proto__ setter and thereby 
prevent anything in the frame from mutating prototypes.

Waldemar: How do you guard against cross-frame prototype mutations?
DaveH: __proto__ is in the "omg, what were we thinking" category.
Waldemar: Opposed to making __proto__ mutate prototypes other than at 
object construction.  This is getting insanely complex.

Unresolved.


One point not recorded here: given MarkM's argument for 
Object.prototype.__proto__ as the one property to delete to remove 
this old beast, what kind of property does that appear to be to ES5's 
Object.getOwnPropertyDescriptor? Arguments pro and con for data 
property (as it appears to be in SpiderMonkey) vs. accessor (JSC 
intended to move to that from its hardcoded magic id handling in Get 
and Put code).


Argument for data property facade: an accessor allows extracting the 
setter from the property descriptor, call it stolen__proto__setter. 
Then if one makes an object with a bespoke proto-object but not 
delegating to Object.prototype:


  var o = { __proto__: Object.create(null) };

an attacker could mutate o's [[Prototype]] via 
stolen__proto__setter.call(o, evil_proto). This is not possible if 
Object.prototype.__proto__ reflects as a data property, because o's 
two-level proto chain is cut off from Object.prototype, so no further 
means of updating [[Prototype]] is available.
Every time I've been thinking of an issue like this, the solution I've 
found was "whoever runs first wins".

Assuming __proto__ is an accessor of Object.prototype:
If trusted code runs first, it can protect itself by removing the setter 
and making the property non-configurable.

If an attacker runs first... you're screwed as you made the demonstration.

Even in the data property case, if an attacker runs first, she can 
probably change quite a lot of built-in prototypes, change built-in 
properties (of any object it has access to) to non-configurable 
accessors, add loggers, all over the place, return evil values to 
function calls.
I have a script [1] which replaces every function with a function that 
is semantically equivalent, but logs "this", the arguments and the 
return value. If an attacker runs this before any other script (before 
initSES.js, for instance :-° ), but adds more harmful than loggers, she 
can really do nasty stuffs.


It seems that the threat may be a bit smaller if __proto__ is a data 
property, but I'm not sure it's significantly smaller than all the 
things you can already do if an attacker runs first.


If you run first, __proto__ being an accessor or a data property does 
not make a difference, you can protect yourself in any case.
The accessor has the advantage that you can have fine-grained control 
over who can change and what cannot. Specifically, you can bind 
__proto__setter, and share this with someone so that this party can 
change the prototype of a given object (or set of objects) you've 
chosen. A data property is more "all (everyone can change the prototype 
of every object inheriting from Object.prototype) or nothing (or no one 
can change the prototype of any object)".



The question that remains is "how can you make sure your trusted run 
first?" which, I think goes beyond ECMAScript scope and should be 
considered in each context (browser, node.js, etc.)


For the browser, I can't think of a good solution that would be backward 
compatible and efficient. Suggestions welcome.


David

[1] https://github.com/DavidBruant/JSTraversers (not really production 
ready and makes some browser crash or hang, because they don't seem to 
appreciate their DOM builtins being traversed)

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

Re: Jan 18 meeting notes

[David Bruant]

Le 19/01/2012 02:27, Waldemar Horwat a écrit :

Brendan: Kill typeof null.  Replace it with Ojbect.isObject?

What would be the semantics of this?
--
Object.isObject(null); // false
Object.isObject({}); // true
// so far so good :-)
Object.isObject(function(){}) // ?
--
I'd like to advocate "true" for the last case. For now, the best way to 
test if something is of type Object (as defined in ES5.1 - 8.6, so 
including function) is to do "o === Object(o)" (an alternative being "o 
!== null && (typeof o === 'object' || typeof o === 'function')", which 
is rather long and I have not seen much) which is a bit hacky and not 
straightforward to read for those who are not familiar with this trick.
If an Object.isObject is introduced, I'd be interested in seeing it 
covering the 8.6 definition.

Or maybe introduce another function for this?



Use __proto__ in object literals to do a put (assuming that a 
__proto__ getter/setter was created in Object.prototype) instead of a 
defineProperty?  All modes or only nonstrict mode?
Allen: Make such use of __proto__ to be a synonym for <|.  If a <| is 
already present, it's an error.

DaveH: __proto__ is ugly.  Don't want it in the language forever.
Waldemar: What about indirect [] expressions that evaluate to 
"__proto__"?  In Firefox they evaluate to accesses that climb the 
prototype chain and usually reach a magic 
getter/setter-that-isn't-a-getter-setter named __proto__ that sits on 
Object.prototype.
MarkM: Likes the ability to delete __proto__ setter and thereby 
prevent anything in the frame from mutating prototypes.

Waldemar: How do you guard against cross-frame prototype mutations?
With a bit of hope, this is not in use in the web now. One idea would be 
that no __proto__ is defined on  otherFrame.Object.prototype, and the 
frame would need to negociate with its parent to get the __proto__ 
setting capability.
This may break the web if currently there is a website which opens 
iframes which relies on __proto__.



DaveH: __proto__ is in the "omg, what were we thinking" category.

Seriously! :-)

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

Re: A different semantics for WeakMap#get default value

[Andreas Rossberg]

On 19 January 2012 07:51, Mark S. Miller  wrote:
>
> Because an instance of InfiniteMap conforms to the full Map contract (given
> that baseMap does and is not otherwise used), we have full Liskov
> substitutability -- you can validly pass an InfiniteMap to an abstraction
> expecting a Map.

PS: Won't the "full Map contract" eventually contain iterators, too?
An infinite map cannot sensibly support those.

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

Re: ES6 doesn't need opt-in

[liorean]

2012/1/10 Herby Vojčík :
> P.S.: I would bet 99% of developers thinks the model is in fact "fallback
> delegation". :-/ It is simpler model that works most of the time. Always
> write locally, always read locally and then look up the prototype chain.

I think that's a question of making a fallacy of equivocation. The
localisation when reading from or writing to a property is a matter of
the value contained in that slot. The access or write permission of
that property is a matter of the actual slot.

-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Block lambda is cool, its syntax isn't

[Axel Rauschmayer]

On Jan 19, 2012, at 8:27 , Brendan Eich wrote:

> To fix (2), how about reviving arrows and avoiding the non-LR(1) parsing for 
> grammar validation problem?

Couldn’t one always freeze such a function shorthand and then get syntax such 
as:

 #(x, y) { x + y }

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

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

Re: A different semantics for WeakMap#get default value

[Andrea Giammarchi]

On Thu, Jan 19, 2012 at 7:51 AM, Mark S. Miller  wrote:

>
> Everyone on this thread, is there any need expressed in this thread that
> is not satisfied by InfiniteMap?
>
>

I would say for "notification purpose"

result = lazyFactory(key, defaultValue);

would be more appropriate otherwise the defaultValue looses completely its
meaning the moment "key" is not there due the first if.

Out of curiosity, Chrome experimental flag does not support get(key,
defaultValue) but get(key) only ... is this something missing or Map and
WeakMap will never support officially the second get() argument?

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