RE: Comments on Meeting Notes

[Luke Hoban]

Brendan Eich wrote:
Hard to say what IE8's share will be, but IE9 did not implement strict mode 
IIRC. IE10 did.

Michał Z. Gołębiowski wrote:
IE10 sort of did. The following code:
(function(){ 'use strict'; return !this; })();
returns false in IE10. Who knows what other
deviations from the standard there are...


That code returns true in IE10 standards mode.  See test262.ecmascript.org for 
tests validating this and other ES5 implementation compatibility.  If you see 
things not covered there, open bugs suggesting new tests: 
https://bugs.ecmascript.org/enter_bug.cgi?product=Test262.

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

Re: Comments on Meeting Notes

[Michał Gołębiowski]

Brendan Eich wrote:
>
> Hard to say what IE8's share will be, but IE9 did not implement strict
> mode IIRC. IE10 did.
>

IE10 sort of did. The following code:
(function(){ 'use strict'; return !this; })();
returns false in IE10. Who knows what other
deviations from the standard there are...


-- 
Michał Z. Gołębiowski
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Meeting Notes

[Brandon Benvie]

I suppose it's worth noting I have an implementation of the ES6 standard
lib implemented using many ES6 features. Notably a significant amount of
@names. At least it's a useful example of them in actual use.
https://github.com/Benvie/continuum/tree/gh-pages/modules


On Tue, Dec 4, 2012 at 9:10 PM, David Herman  wrote:

> On Dec 4, 2012, at 4:03 PM, Brendan Eich  wrote:
>
> > We cannot have __legacy__ in ES6 and hope to get rid of it "later" IMHO.
> We'll be committing to it as normative API for the indefinite future.
>
> +1
>
> You don't build web functionality with the intention of removing it. It
> just doesn't work that way.
>
> Dave
>
> ___
> 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: Comments on Meeting Notes

[David Herman]

On Dec 4, 2012, at 4:03 PM, Brendan Eich  wrote:

> We cannot have __legacy__ in ES6 and hope to get rid of it "later" IMHO. 
> We'll be committing to it as normative API for the indefinite future.

+1

You don't build web functionality with the intention of removing it. It just 
doesn't work that way.

Dave

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

Re: Comments on Meeting Notes

[Brendan Eich]

Could you specify more? If you mean SunSpider (2007) or V8/Octane, I 
have some well-known bones to pick. These have sucked up a lot (not all) 
of the oxygen available for the brain cells developers and casually 
interested parties use to track "JS performance", but due to a 
who's-on-first effect, not just because "benchmarks".


IOW, good luck making new strict-mode benchmarks that displace these.

Also, good luck getting SunSpider or V8/Octane to enable "use strict"! 
Paging Dr. Rossberg on the latter :-P.


/be

Mark S. Miller wrote:

On Tue, Dec 4, 2012 at 3:57 PM, Brendan Eich  wrote:

Benchmarks won't cut it if there's no organic developer pressure.


That is not the behavior I've observed in response to benchmarks,
either among JS implementors, or in the industry as a whole. Developer
pressure and actual usage patterns *should* trump benchmarks. What
I've generally seen is the opposite.

--
 Cheers,
 --MarkM
___
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: (Map|Set|WeakMap)#set() returns `this` ?

[Andrea Giammarchi]

as discussed before, the problem with setDefault() approach you are
suggesting is that the dict(), at least in JS, will be created in any case.

var newDict = a.setDefault(k1, dict());

above operation will invoke dict() regardless k1 was present or less and
this is not good for anyone: RAM, CPU, GC, etc

the initial pattern is and wants to be like that so that not a single
pointless operation is performed when/if the key is already there.

var o = obj.has(key) ? obj.get(key) : obj.set(key, dict()); // <== see
dict, never called if key

quick and dirty

var o = obj.get(key) || obj.set(key, dict());

With current pattern, and my only concern is that after this decision every
other `set()` like pattern will return this even where not optimal, I have
to do

var o = obj.has(key) ? obj.get(key) : obj.set(key, dict()).get(key);

meh ... but I can survive :D











On Tue, Dec 4, 2012 at 4:49 PM, Tab Atkins Jr.  wrote:

> On Mon, Dec 3, 2012 at 2:21 PM, Andrea Giammarchi
>  wrote:
> > IMHO, a set(key, value) should return the value as it is when you
> address a
> > value
> >
> > var o = m.get(k) || m.set(k, v); // o === v
> >
> > // equivalent of
> >
> > var o = m[k] || (m[k] = v); // o === v
>
> If this pattern is considered sufficiently useful (I think it is), we
> should handle it directly, as Python does.  Python dicts have a
> setDefault(key, value) method which implements this pattern exactly -
> if the key is in the dict, it returns its associated value (acts like
> a plain get()); if it's not, it sets the key to the passed value and
> then returns it.  Using this pattern is not only clearer, but avoids
> repetition (of "m" and "k" in your example), and actually chains - I
> use setDefault all the time when working with nested dicts.
>
> (For example, if I have a sparse 2d structure implemented with nested
> dicts, I can safely get/set a terminal value with code like
> "a.setDefault(k1, dict()).set(k2, v)".  If that branch hadn't been
> touched before, this creates the nested dict for me.  If it has, I
> create a throwaway empty dict, which is cheap.  If JS ever grows
> macros, you can avoid the junk dict as well.)
>
> I prefer the plain methods to work as they are currently specified,
> where they return this.
>
> ~TJ
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Tab Atkins Jr.]

On Mon, Dec 3, 2012 at 2:21 PM, Andrea Giammarchi
 wrote:
> IMHO, a set(key, value) should return the value as it is when you address a
> value
>
> var o = m.get(k) || m.set(k, v); // o === v
>
> // equivalent of
>
> var o = m[k] || (m[k] = v); // o === v

If this pattern is considered sufficiently useful (I think it is), we
should handle it directly, as Python does.  Python dicts have a
setDefault(key, value) method which implements this pattern exactly -
if the key is in the dict, it returns its associated value (acts like
a plain get()); if it's not, it sets the key to the passed value and
then returns it.  Using this pattern is not only clearer, but avoids
repetition (of "m" and "k" in your example), and actually chains - I
use setDefault all the time when working with nested dicts.

(For example, if I have a sparse 2d structure implemented with nested
dicts, I can safely get/set a terminal value with code like
"a.setDefault(k1, dict()).set(k2, v)".  If that branch hadn't been
touched before, this creates the nested dict for me.  If it has, I
create a throwaway empty dict, which is cheap.  If JS ever grows
macros, you can avoid the junk dict as well.)

I prefer the plain methods to work as they are currently specified,
where they return this.

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

Re: Comments on Meeting Notes

[Mark S. Miller]

On Tue, Dec 4, 2012 at 3:57 PM, Brendan Eich  wrote:
> Benchmarks won't cut it if there's no organic developer pressure.

That is not the behavior I've observed in response to benchmarks,
either among JS implementors, or in the industry as a whole. Developer
pressure and actual usage patterns *should* trump benchmarks. What
I've generally seen is the opposite.

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

Re: Comments on Meeting Notes

[Brendan Eich]

Herby Vojčík wrote:
I am convinced it is doable (to have __legacy__ names but move to use 
the better way once it is present) with the example of 
__defineGetter__ & Co.


I suggest those are bad precedents. They never were implemented in IE, 
which led to ES5's meta-object APIs.


I confess I don't know how this is in the wild, just me being here 
makes me a kind of early adopter with bias for using the new/right 
way, but I feel those (__defineGetter__ and company) are of little use 
now and the world successfully moved to Object.defineProperty / 
{get,set} x() in literals.


The Object.defineProperty required ES5 and was also predicated on IE 
never adopteding dunder-define/lookup.


The object literal notation came from SpiderMonkey long ago, BTW -- it 
was not new and invented only in ES5.



So why this wouldn't be possible for others?


Because of the above, at least. Note how __proto__ also never made it to 
IE but was more frequently used than __define/lookup, especially on the 
"mobile web" (post-iPhone, because WebKit reverse-engineered __proto__). 
One size does not fit all but we have particular precedents from which 
to reason, and the particulars do matter.


We cannot have __legacy__ in ES6 and hope to get rid of it "later" IMHO. 
We'll be committing to it as normative API for the indefinite future.


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

Re: Comments on Meeting Notes

[Brendan Eich]

Allen Wirfs-Brock wrote:

On Dec 4, 2012, at 1:28 PM, Brendan Eich wrote:

Mark S. Miller wrote:

* It deoptimizes, e.g. a strict-mode function must be optimized to copy
actual parameter values into arguments if it could use the arguments object.

This one I just don't buy at all. In a strict function f, f.arguments
is poisoned. f's arguments would only need to be reified if f
statically mentions "arguments" or if f has a statically apparent use
of the direct eval operator. For all other cases, no arguments object
need be created, and therefore no copying is needed.

Right, that's what I tried to say by "could use the arguments object". Nothing 
to do with hated f.arguments.

So every strict function that uses arguments pays a copying price on entry in a 
naive implementation. Pushing the copies out till just before there might be an 
aliasing store is an optimization that could be done in a more sophisticated 
implementation, but engines don't do it currently and feel little pressure to 
do so. Chicken and egg.


The timing of copying is only an issue if the function actually assigns to a 
formal parameter.  Such assignments should be pretty easy to (conservatively) 
statically check for.


I'm telling you what engines do. Not what they might do. I did 
assignment analysis in SpiderMonkey for Firefox 3.6, it was helpful in 
its day. I think a bunch has been ripped out because modern JITs don't 
need it.



So, I guess I agree with Mark on this one.  Implementations could do a pretty 
good job of optimizing strict mode function parameters if they thought it was 
necessary.  It probably needs to be driven by benchmarks.


You are not responding to the point I made, cited above: " engines don't 
do it currently and feel little pressure to do so. Chicken and egg."


Benchmarks won't cut it if there's no organic developer pressure.

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

Re: Comments on Meeting Notes

[Mark S. Miller]

On Tue, Dec 4, 2012 at 2:18 PM, Mark S. Miller  wrote:
> https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ

I have received private email complaining about the biased language in
this poll, and that as a result it is merely a push poll
. I agree. I encourage someone
who is capable of writing a proper poll to do so and post it. In
anticipation of a proper poll, I withdraw this one. Thanks.

My apologies to those who have already taken the time to answer this one.



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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Rick Waldron]

On Tue, Dec 4, 2012 at 3:50 PM, Brendan Eich  wrote:

> The survey I'd like to see is among underscore, jQuery, and other popular
> libraries (go by NPM dependency frequency and client-side use frequency),
> how do set-like methods work: return-this or return-v?
>
>
underscore and jQuery side with

1. returning the calling object
2. returning a new object of the same "kind", but with the results of the
operation.

jQuery objects themselves are similar to a set, most operations on the set
itself result in returning a new jQuery object (set) that reflects the
results of the operation. As I explained previously, the reason it returns
a new jQuery object is to support the end() and addBack() methods by
storing the original as a property of the current, this that allows either
restoring the original set to it's pre-operation state or adding the
original set to the current set. If this were not an API that we supported,
jQuery could just as easily be a custom wrapper over an ES6 Set.

underscore actually has a special method called _.chain() that returns a
wrapped object that allows for chaining all of the underscore APIs—until
value() is called, which closely matches the examples I gave yesterday.
underscore has a _.defaults()  function that returns the mutated object
after applying a default set of properties and values (similar to
_.extend()). There is no analogous Set api in underscore.


for npm in order of most dependencies:

1. underscore (see above).

2. request.

   - Any API that "sets" something, returns this (
   https://github.com/mikeal/request/blob/master/main.js#L735-L758 )
   - There is a lib that Mikeal also wrote "form-data" that has an append
   method that does _not_ return this

3. async. Nothing comparable

4. express.

   - app.set, and subsequently all aliases, returns this (
   
https://github.com/visionmedia/express/blob/master/lib/application.js#L250-L261
   )
   - response.set, and subsequently all aliases, returns this (
   https://github.com/visionmedia/express/blob/master/lib/response.js#L37-L40
   )

5. optimist.

   - every operation that is not a "get" returns self as this; (
   https://github.com/substack/node-optimist/blob/master/index.js)

6. commander.

   - nearly every operation that is not a "get" returns this; (
   https://github.com/visionmedia/commander.js/blob/master/index.js)

7. colors

   - setTheme returns the theme that was set

8. uglify. Nothing comparable

9. connect.

   - Too much to review, but it's primary API that "sets" values,  returns
   this (see examples in readme)

10. socket.io

   - Too much to review, nearly everything returns this (
   https://github.com/LearnBoost/socket.io/blob/master/lib/socket.js)


When I was researching whether or not it was worthwhile to pursue this
discussion, I reviewed most of this stuff, as well as web-focused libs.

At the moment I have to head out, so I can't continue to research this, but
I'll gladly spend as many hours as anyone thinks is necessary to prove my
position.

Rick











> This is closer than a people-survey to mapping the cowpath.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Meeting Notes

[Allen Wirfs-Brock]

On Dec 4, 2012, at 1:28 PM, Brendan Eich wrote:

> Mark S. Miller wrote:
>> ...
> 
>>> * It deoptimizes, e.g. a strict-mode function must be optimized to copy
>>> actual parameter values into arguments if it could use the arguments object.
>> 
>> This one I just don't buy at all. In a strict function f, f.arguments
>> is poisoned. f's arguments would only need to be reified if f
>> statically mentions "arguments" or if f has a statically apparent use
>> of the direct eval operator. For all other cases, no arguments object
>> need be created, and therefore no copying is needed.
> 
> Right, that's what I tried to say by "could use the arguments object". 
> Nothing to do with hated f.arguments.
> 
> So every strict function that uses arguments pays a copying price on entry in 
> a naive implementation. Pushing the copies out till just before there might 
> be an aliasing store is an optimization that could be done in a more 
> sophisticated implementation, but engines don't do it currently and feel 
> little pressure to do so. Chicken and egg.

The timing of copying is only an issue if the function actually assigns to a 
formal parameter.  Such assignments should be pretty easy to (conservatively) 
statically check for.

So, you should be able to avoid copying on entry if there is no direct eval and 
no assignments to formal parameters.  A pretty common case.

If there is a reference to arguments (and no assignment to formals), you should 
only need to copy if a Put is actually made to the arguments object.  This is 
also rare and potentially optimizable in various ways.

So, I guess I agree with Mark on this one.  Implementations could do a pretty 
good job of optimizing strict mode function parameters if they thought it was 
necessary.  It probably needs to be driven by benchmarks.

Allen


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

Re: Comments on Meeting Notes

[Mark S. Miller]

https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: lexical 'super' in arrow functions?

[Allen Wirfs-Brock]

On Dec 4, 2012, at 1:54 PM, Brandon Benvie wrote:

> I made a somewhat moreinterestling colored and (to me) more readable 
> version of the ES6 spec (previous one from last) using jorendorff's html 
> rendition as a foundation. Some may find this interesting, and some may be 
> blinded for life: http://benvie.github.com/es-spec-html/

He-he, I kinda like it!  Especially the algorithms, although I miss the outline 
numbering style.

Hopefully, someday I'll have time to straighten-out all of the Word styling 
disasters that have accumulated over 6+ editions. That should make life easier 
for various html renders.

Allen






> 
> 
> On Tue, Dec 4, 2012 at 12:56 PM, Allen Wirfs-Brock  
> wrote:
> There is a long history of people publishing annotated versions of language 
> standards that add informative materials.  The Ecma copyright even explicitly 
> allows for this. 
> 
> I think I've said before that there is an opportunity here for somebody to 
> run with this idea for ECMAScript. You don't even need to have TC39 involved. 
>  (But there probably are T39 members, like Rick,  who may want to contribute 
> or even take the lead.)
> 
> Allen
> 
> On Dec 4, 2012, at 8:26 AM, Rick Waldron wrote:
> 
>> 
>> On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:
>> 
>>> Language specification is a difficult task, especially when handling a 
>>> complex language, legacy spec style, and wide variety of audience 
>>> background, not to mention a committee with lots of feedback and opinions.  
>>> We are very lucky that Allen does the job he does.
>>> 
>>> That also means we shouldn't make it harder, or ask the spec to bear 
>>> burdens it doesn't need to handle.  JavaScript is blessed with numerous 
>>> excellent books describing how to use the language and what various 
>>> features are for, including Dave's new book. That's the place to go for 
>>> description and explanation, not the spec.
>>> 
>>> Sam
>>> 
>> Agreed. Community members that care enough to know about and stay up to date 
>> with ES6 progress could work together with TC39 to create something similar 
>> to http://dmitrysoshnikov.com/ecmascript/es5-chapter-0-introduction/ 
>> 
>> Anyone interested in working on something like this should contact me at 
>> this email address
>> 
>> Rick
>>  
>>> ___
>>> 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
> 
> 
> ___
> 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: How to count the number of symbols in a string?

[Norbert Lindenberg]

On Dec 4, 2012, at 11:43 , David Bruant wrote:

> Le 04/12/2012 20:25, Jason Orendorff a écrit :
>> On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens  wrote:
>> 
>>> My guess would be that in 99% of all cases where `String.prototype.length` 
>>> is used the intention is to count the code points, not the UCS-2/UTF-16 
>>> code units.
>>> 
>> I don't think this is right. My guess is that in most cases where it matters 
>> either way, the intention is to get a count that's consistent with 
>> .charAt(), .indexOf(), .slice(), RegExp match.index, and every other place 
>> where string indexes are used.
> I think Twitter has a bug as mentioned earlier in the thread and that's 
> unrelated to consistency with the method you're mentioning.

One example isn't enough to support a "99% of all cases" claim. And I agree 
with Jason - many uses of String.length are related to some sort of iteration 
over the code units of the String, and then consistency with indices is 
critical. Showing the length of a string to the user is a rare (although 
important) case.

> I however agree that if something is added to get the actual length, a whole 
> set of methods needs to be added too.

Which proposal are you referring and agreeing to?

>> That said, of course this is a sensible feature to add; but calling it 
>> ".realLength" wouldn't help anyone understand the rather fine distinction at 
>> issue.
> Maybe the solution lies in finding the right prefix to define .*length, 
> .*charAt(), .*indexOf(), etc. Maybe "CP" for "code points" .CPlength? 
> .cpLength/cpCharAt/cpIndexOf... ?

"cp" to indicate that code point indices? I think using two parallel index 
systems would only create confusion. Most string processing, including indexOf, 
works fine with supplementary characters without doing anything special for 
them.  We need to provide a foundation that lets developers easily support 
supplementary characters in functionality that needs to be aware of them, but 
in many applications few changes will be required.

> While you're talking about regexps, I think there is an issue with current 
> RegExps. Mathias will know better. Could a new flag solve the issue?

RegExp does require major changes to support supplementary characters. The 
proposal accepted for ES6 (although not integrated into the spec yet) is at
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html#RegExp

Are you aware of issues not addressed there?

Norbert


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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Andrea Giammarchi]

agreed ... but then these analysis should be done before making decisions
in TC39 meeting notes.

If this was the case then, as I have said, I am OK with the decision ( de
gustibus )

br


On Tue, Dec 4, 2012 at 12:50 PM, Brendan Eich  wrote:

> The survey I'd like to see is among underscore, jQuery, and other popular
> libraries (go by NPM dependency frequency and client-side use frequency),
> how do set-like methods work: return-this or return-v?
>
> This is closer than a people-survey to mapping the cowpath.
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: lexical 'super' in arrow functions?

[Brandon Benvie]

I made a somewhat moreinterestling colored and (to me) more readable
version of the ES6 spec (previous one from last) using jorendorff's html
rendition as a foundation. Some may find this interesting, and some may be
blinded for life: http://benvie.github.com/es-spec-html/


On Tue, Dec 4, 2012 at 12:56 PM, Allen Wirfs-Brock wrote:

> There is a long history of people publishing annotated versions of
> language standards that add informative materials.  The Ecma copyright even
> explicitly allows for this.
>
> I think I've said before that there is an opportunity here for somebody to
> run with this idea for ECMAScript. You don't even need to have TC39
> involved.  (But there probably are T39 members, like Rick,  who may want to
> contribute or even take the lead.)
>
> Allen
>
> On Dec 4, 2012, at 8:26 AM, Rick Waldron wrote:
>
>
> On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:
>
> Language specification is a difficult task, especially when handling a
> complex language, legacy spec style, and wide variety of audience
> background, not to mention a committee with lots of feedback and opinions.
> We are very lucky that Allen does the job he does.
>
> That also means we shouldn't make it harder, or ask the spec to bear
> burdens it doesn't need to handle.  JavaScript is blessed with numerous
> excellent books describing how to use the language and what various
> features are for, including Dave's new book. That's the place to go for
> description and explanation, not the spec.
>
> Sam
>
> Agreed. Community members that care enough to know about and stay up to
> date with ES6 progress could work together with TC39 to create something
> similar to
> http://dmitrysoshnikov.com/ecmascript/es5-chapter-0-introduction/
>
> Anyone interested in working on something like this should contact me at
> this email address
>
> Rick
>
>
> ___
> 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
>
>
>
> ___
> 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: Comments on Meeting Notes

[Brendan Eich]

Mark S. Miller wrote:

On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich  wrote:

Kevin Smith wrote:

I recommend allowing let declarations only in strict mode.  This is the
simple, backwards-compatible path.  Strict mode only has a bad reputation
because, in ES5, it is restrictive-only.  There are (almost) no carrots
leading users there.

Strict mode has a bad rep for two other important causes:

* It forks runtime semantics, which requires careful testing in
pre-ES5-strict implementations. This has been a real-world problem, multiple
times.


I buy this for old code that needs to just keep working, bugs and all,
without human attention. But strict mode can be opted into
incrementally, per program or even per function.


Real world problem: concatenation.


  For any portion of
code being actively maintained, the non-strict semantics are a hazard.
Admittedly, today with the co-existence of ES3 and ES5, the forking
issue does create an additional problem, because strict code has to
work non-strict as well in old browsers. But pre-ES5 browsers are
finally starting to fade away for real. By the time ES6 rolls out, I
don't expect much ES6 code to be concerned about also running on ES3.


Hard to say what IE8's share will be, but IE9 did not implement strict 
mode IIRC. IE10 did.



* It deoptimizes, e.g. a strict-mode function must be optimized to copy
actual parameter values into arguments if it could use the arguments object.


This one I just don't buy at all. In a strict function f, f.arguments
is poisoned. f's arguments would only need to be reified if f
statically mentions "arguments" or if f has a statically apparent use
of the direct eval operator. For all other cases, no arguments object
need be created, and therefore no copying is needed.


Right, that's what I tried to say by "could use the arguments object". 
Nothing to do with hated f.arguments.


So every strict function that uses arguments pays a copying price on 
entry in a naive implementation. Pushing the copies out till just before 
there might be an aliasing store is an optimization that could be done 
in a more sophisticated implementation, but engines don't do it 
currently and feel little pressure to do so. Chicken and egg.



  Leave non-strict as is, and let users opt-in to "let".  An excellent
carrot.

The problem is precisely that users cannot opt into "let" alone by its novel
syntax. Opting into strict mode may or may not win but it has added costs
and benefits, and that means let adoption will suffer.


> From what was said at the TC39 meeting, the main "cost" is simply that
strict mode has a bad rep with the community. This bad rep, to the
extent it still exists, is largely superstition.


No, see above.

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

Re: Comments on Meeting Notes

[Herby Vojčík]

Brendan Eich wrote:

Herby Vojčík wrote:

recommend a more conservative approach for ES6: use the plain string
"iterator" as the protocol hook. Once the syntactic issues have been


I'd say not "iterator". This is a special identifier, so to speak
"instead-of-symbol-internal-name", so I would go for __iterator__.
Same for other few examples which may have benefited from symbols but
cannot.


TC39 probably will barf, but you make a good point -- so good it's what
I implemented in JS1.7 and up in SpiderMonkey.


I didn't know, really. :-)


It would create consistent __legacy__ realm where each member should
be obsoleted by evangelizing the right way once it appears (__proto__
won't have one, it is too stuck; __{define|lookup}{Getter|Setter}__
already have the right way; it can be same for __iterator__,
__create__, __hasInstance__ etc.).


We hope to skip this legacy and leave it in the multiverse of
alternative realities. Can we do it? If not now, why do you think we
could do it later, when the dunder-names are sucking all the oxygen out
of the "use symbols" room?


I am convinced it is doable (to have __legacy__ names but move to use 
the better way once it is present) with the example of __defineGetter__ 
& Co. I confess I don't know how this is in the wild, just me being here 
makes me a kind of early adopter with bias for using the new/right way, 
but I feel those (__defineGetter__ and company) are of little use now 
and the world successfully moved to Object.defineProperty / {get,set} 
x() in literals. So why this wouldn't be possible for others?



/be


Herby

P.S.: And even __proto__ could be changed to use @parent or similar 
syntax later. I already proposed it here on the list a few weeks ago. 
Every __legacy__ could have its note in spec, saying what should be used 
instead. And just wait until it catches up (while pushing it constantly).

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

Re: Comments on Meeting Notes

[Mark S. Miller]

On Tue, Dec 4, 2012 at 1:04 PM, Mark S. Miller  wrote:
> On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich  wrote:
>> Kevin Smith wrote:
>>>
>>> I recommend allowing let declarations only in strict mode.  This is the
>>> simple, backwards-compatible path.  Strict mode only has a bad reputation
>>> because, in ES5, it is restrictive-only.  There are (almost) no carrots
>>> leading users there.
>>
>>
>> Strict mode has a bad rep for two other important causes:
>>
>> * It forks runtime semantics, which requires careful testing in
>> pre-ES5-strict implementations. This has been a real-world problem, multiple
>> times.
>
> I buy this for old code that needs to just keep working, bugs and all,
> without human attention. But strict mode can be opted into
> incrementally, per program or even per function. For any portion of
> code being actively maintained, the non-strict semantics are a hazard.
> Admittedly, today with the co-existence of ES3 and ES5, the forking
> issue does create an additional problem, because strict code has to
> work non-strict as well in old browsers. But pre-ES5 browsers are
> finally starting to fade away for real. By the time ES6 rolls out, I
> don't expect much ES6 code to be concerned about also running on ES3.
>
>
>> * It deoptimizes, e.g. a strict-mode function must be optimized to copy
>> actual parameter values into arguments if it could use the arguments object.
>
> This one I just don't buy at all. In a strict function f, f.arguments
> is poisoned. f's arguments would only need to be reified if f
> statically mentions "arguments" or if f has a statically apparent use
> of the direct eval operator. For all other cases, no arguments object
> need be created, and therefore no copying is needed.
>
>
>>>  Leave non-strict as is, and let users opt-in to "let".  An excellent
>>> carrot.
>>
>>
>> The problem is precisely that users cannot opt into "let" alone by its novel
>> syntax. Opting into strict mode may or may not win but it has added costs
>> and benefits, and that means let adoption will suffer.
>
> From what was said at the TC39 meeting, the main "cost" is simply that
> strict mode has a bad rep with the community. This bad rep, to the
> extent it still exists, is largely superstition. However, the
> committee, in fear of this irrationality among the community, is about
> to make some bad decisions. This es-discuss list is, perhaps,
> adequately representative of the community that if there's an outcry,
> not to further cruft up the language for the sake of making ES6
> features available in strict mode at all costs, then perhaps we can

Obviously, that should have been "...available in non-strict mode at all costs"


> get the committee to revisit some of those decisions.
>
>
>
>>
>> 1JS wants new syntax to be its own opt-in. The only issue with making let
>> work in non-strict code is the obscure let[i] = j; pattern. If no one
>> actually wrote such code (it's possible; public web searches by big
>> search-engine companies, or at least one so far, found nothing), then we
>> should not risk reduced let adoption by yoking it to the heavier burden of
>> strict mode.
>
> By the time ES6 is a reality, there won't be anything heavy about
> strict mode, except the committee's fear of lingering superstition
> among developers.
>
>
>>
>> /be
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Cheers,
> --MarkM



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

Re: Comments on Meeting Notes

[Mark S. Miller]

On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich  wrote:
> Kevin Smith wrote:
>>
>> I recommend allowing let declarations only in strict mode.  This is the
>> simple, backwards-compatible path.  Strict mode only has a bad reputation
>> because, in ES5, it is restrictive-only.  There are (almost) no carrots
>> leading users there.
>
>
> Strict mode has a bad rep for two other important causes:
>
> * It forks runtime semantics, which requires careful testing in
> pre-ES5-strict implementations. This has been a real-world problem, multiple
> times.

I buy this for old code that needs to just keep working, bugs and all,
without human attention. But strict mode can be opted into
incrementally, per program or even per function. For any portion of
code being actively maintained, the non-strict semantics are a hazard.
Admittedly, today with the co-existence of ES3 and ES5, the forking
issue does create an additional problem, because strict code has to
work non-strict as well in old browsers. But pre-ES5 browsers are
finally starting to fade away for real. By the time ES6 rolls out, I
don't expect much ES6 code to be concerned about also running on ES3.


> * It deoptimizes, e.g. a strict-mode function must be optimized to copy
> actual parameter values into arguments if it could use the arguments object.

This one I just don't buy at all. In a strict function f, f.arguments
is poisoned. f's arguments would only need to be reified if f
statically mentions "arguments" or if f has a statically apparent use
of the direct eval operator. For all other cases, no arguments object
need be created, and therefore no copying is needed.


>>  Leave non-strict as is, and let users opt-in to "let".  An excellent
>> carrot.
>
>
> The problem is precisely that users cannot opt into "let" alone by its novel
> syntax. Opting into strict mode may or may not win but it has added costs
> and benefits, and that means let adoption will suffer.

>From what was said at the TC39 meeting, the main "cost" is simply that
strict mode has a bad rep with the community. This bad rep, to the
extent it still exists, is largely superstition. However, the
committee, in fear of this irrationality among the community, is about
to make some bad decisions. This es-discuss list is, perhaps,
adequately representative of the community that if there's an outcry,
not to further cruft up the language for the sake of making ES6
features available in strict mode at all costs, then perhaps we can
get the committee to revisit some of those decisions.



>
> 1JS wants new syntax to be its own opt-in. The only issue with making let
> work in non-strict code is the obscure let[i] = j; pattern. If no one
> actually wrote such code (it's possible; public web searches by big
> search-engine companies, or at least one so far, found nothing), then we
> should not risk reduced let adoption by yoking it to the heavier burden of
> strict mode.

By the time ES6 is a reality, there won't be anything heavy about
strict mode, except the committee's fear of lingering superstition
among developers.


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



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

Re: Comments on Meeting Notes

[Brendan Eich]

Herby Vojčík wrote:

recommend a more conservative approach for ES6:  use the plain string
"iterator" as the protocol hook.  Once the syntactic issues have been


I'd say not "iterator". This is a special identifier, so to speak 
"instead-of-symbol-internal-name", so I would go for __iterator__. 
Same for other few examples which may have benefited from symbols but 
cannot.


TC39 probably will barf, but you make a good point -- so good it's what 
I implemented in JS1.7 and up in SpiderMonkey.


It would create consistent __legacy__ realm where each member should 
be obsoleted by evangelizing the right way once it appears (__proto__ 
won't have one, it is too stuck; __{define|lookup}{Getter|Setter}__ 
already have the right way; it can be same for __iterator__, 
__create__, __hasInstance__ etc.). 


We hope to skip this legacy and leave it in the multiverse of 
alternative realities. Can we do it? If not now, why do you think we 
could do it later, when the dunder-names are sucking all the oxygen out 
of the "use symbols" room?


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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Brendan Eich]

The survey I'd like to see is among underscore, jQuery, and other 
popular libraries (go by NPM dependency frequency and client-side use 
frequency), how do set-like methods work: return-this or return-v?


This is closer than a people-survey to mapping the cowpath.

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

Re: [[Call]] pass through result completion to callee

[Brendan Eich]

Allen Wirfs-Brock wrote:

On Dec 4, 2012, at 11:32 AM, Brendan Eich wrote:


In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also 13.2.2 
[[Construct]], which layers on [[Call]], so [[Call]] is the lowest layer single 
algorithm that has to deal with completions.

Pushing down into FunctionBody is ok if there are no other uses of FunctionBody 
that do not want this common processing, i.e., where evaluation does not funnel 
through [[Call]]. Are there no other such uses?

ES1-5 all handle the cases via something like

4. If result.type is throw then throw result.value.
5. If result.type is return then return result.value.
6. Otherwise result.type must be normal. Return undefined.

in 13.2.1 [[Call]].

Conserving this code under ES6's relocated [[Call]] internal method seems best, 
all else equal.


I don't really think so. First we not have multiple implementations of [[Call]] 
(always could have, but it's now more obvious) and trap handlers implementing 
[[Call]] don't have direct access to Completion Records so they can't exactly 
emulate ordinary function [[Call]] does.


This is a good reason!


Also, [[Call]] is mostly about defining with the invocation mechanism, not 
about the statement level semantics of a function body.  Determination of a 
function's result (including handling of internal returns and throws) seems 
like something that should be part of the specified semantics of a function 
body rather than of the [[Call]] MOP entry point.


It should be one of the two, but for ES1-5 it was [[Call]], which was 
*not* a MOP entry point. That change makes the good reason you gave above.



As to the other point, nobody evaluates FunctionBody that doesn't want this 
semantics so it still is at one place and IMO the best place.


Good to know, thanks.

/be

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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Rick Waldron]

On Tue, Dec 4, 2012 at 3:07 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> it would be nice to add a #put(key, value) that returns value and see what
> developers prefer on daily basis tasks :-)
>
> anyway, if it won't change, it's OK, I had my answer, thanks
>


I like surveying actual developer-users like this, despite the committee's
aversion to "design-by-survey". I sent out a survey 2 weeks ago and
received 381 responses, 256 for return-this and 125 for return something
else (undefined, the new length or size, the value). If the results had
been different, I would've removed the item from the agenda entirely, but
they are as I expected them to be and I feel compelled to take that into
consideration. This survey was not mentioned as a part of my proposal and
therefore had no influence on the decision made by the committee.


Rick





>
> On Tue, Dec 4, 2012 at 12:03 PM, Rick Waldron wrote:
>
>>
>>
>>
>> On Tue, Dec 4, 2012 at 2:46 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> for develoeprs I meant jQuery users too, being one of th emost popular
>>> API out there.
>>>
>>> What I meant with jQuery#add method is that last thing added is the one
>>> returned, it does nto return the initial object, it returns the new result
>>> out of a merge but this is not the initial this, this is a new thing with
>>> latest added thing in.
>>>
>>
>> That is exactly what I described—the case for returning a fresh jQuery
>> object exists to support end() (http://api.jquery.com/end/) which allows
>> you to chain operations (eg. filter->apply css or something) and restore
>> the original jQuery object (matching set of elements) by keeping a
>> reference to that object stored as a property of the new jQuery object.
>> This mechanism is irrelevant in the comparison of Set API semantics.
>>
>> Rick
>>
>>
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Andrea Giammarchi]

it would be nice to add a #put(key, value) that returns value and see what
developers prefer on daily basis tasks :-)

anyway, if it won't change, it's OK, I had my answer, thanks


On Tue, Dec 4, 2012 at 12:03 PM, Rick Waldron wrote:

>
>
>
> On Tue, Dec 4, 2012 at 2:46 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> for develoeprs I meant jQuery users too, being one of th emost popular
>> API out there.
>>
>> What I meant with jQuery#add method is that last thing added is the one
>> returned, it does nto return the initial object, it returns the new result
>> out of a merge but this is not the initial this, this is a new thing with
>> latest added thing in.
>>
>
> That is exactly what I described—the case for returning a fresh jQuery
> object exists to support end() (http://api.jquery.com/end/) which allows
> you to chain operations (eg. filter->apply css or something) and restore
> the original jQuery object (matching set of elements) by keeping a
> reference to that object stored as a property of the new jQuery object.
> This mechanism is irrelevant in the comparison of Set API semantics.
>
> Rick
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Meeting Notes

[Kevin Smith]

> I would like to defend Dave against Kevin's "wildly".


Yeah - it *was* a little inflammatory.  Sorry, Dave.  I think you rock, of
course  : )

That the default loader knows about pathnames and ".js" is a good thing in
> my view. You want something else, write another loader.


Actually, I feel like I'm arguing from a position of ignorance at this
point, so I'll wait until Dave gives us a more complete picture before
abusing anyone further on this subject.

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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Rick Waldron]

On Tue, Dec 4, 2012 at 2:46 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> for develoeprs I meant jQuery users too, being one of th emost popular API
> out there.
>
> What I meant with jQuery#add method is that last thing added is the one
> returned, it does nto return the initial object, it returns the new result
> out of a merge but this is not the initial this, this is a new thing with
> latest added thing in.
>

That is exactly what I described—the case for returning a fresh jQuery
object exists to support end() (http://api.jquery.com/end/) which allows
you to chain operations (eg. filter->apply css or something) and restore
the original jQuery object (matching set of elements) by keeping a
reference to that object stored as a property of the new jQuery object.
This mechanism is irrelevant in the comparison of Set API semantics.

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

Re: [[Call]] pass through result completion to callee

[Allen Wirfs-Brock]

On Dec 4, 2012, at 11:32 AM, Brendan Eich wrote:

> In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also 
> 13.2.2 [[Construct]], which layers on [[Call]], so [[Call]] is the lowest 
> layer single algorithm that has to deal with completions.
> 
> Pushing down into FunctionBody is ok if there are no other uses of 
> FunctionBody that do not want this common processing, i.e., where evaluation 
> does not funnel through [[Call]]. Are there no other such uses?
> 
> ES1-5 all handle the cases via something like
> 
> 4. If result.type is throw then throw result.value.
> 5. If result.type is return then return result.value.
> 6. Otherwise result.type must be normal. Return undefined.
> 
> in 13.2.1 [[Call]].
> 
> Conserving this code under ES6's relocated [[Call]] internal method seems 
> best, all else equal.

I don't really think so. First we not have multiple implementations of [[Call]] 
(always could have, but it's now more obvious) and trap handlers implementing 
[[Call]] don't have direct access to Completion Records so they can't exactly 
emulate ordinary function [[Call]] does. 

Also, [[Call]] is mostly about defining with the invocation mechanism, not 
about the statement level semantics of a function body.  Determination of a 
function's result (including handling of internal returns and throws) seems 
like something that should be part of the specified semantics of a function 
body rather than of the [[Call]] MOP entry point.

As to the other point, nobody evaluates FunctionBody that doesn't want this 
semantics so it still is at one place and IMO the best place.

Allen


> 
> /be
> 
> Yusuke Suzuki wrote:
>> Thanks.
>> 
>> I've just filed it to bugs.ecmascript.org  
>> https://bugs.ecmascript.org/show_bug.cgi?id=1119
>> 
>>It appears to me that the best fix is in the evaluation semantics
>>of FunctionBody.
>> 
>> 
>> Looks nice to me too.
>> 
>> 
>> On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock > > wrote:
>> 
>>(Note that this is probably the sort of issue that would be better
>>to report to bugs.ecmascript.org )
>> 
>>Yes, that looks like an issue.  It appears to me that the best fix
>>is in the evaluation semantics of FunctionBody.  It should take
>>care of Return completions and also make sure that normal
>>completions yield undefined and not empty.
>> 
>>Letting Return completions escape from functions was needed when
>>we were considering supporting block lambdas but isn't need now.
>> 
>>Allen
>> 
>> 
>> 
>> 
>> 
>>On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote:
>> 
>>>Hello all,
>>> 
>>>Because of 8.3.19.1 step 17, [[Call]] returns result completion
>>>even if result.type isn't return.
>>>As the result, [[Call]] may return NormalCompletion(empty), is it
>>>expected behavior?
>>>I think we should change empty to undefined.
>>> 
>>>For example,
>>> 
>>>function test() {
>>>  var i;
>>>}
>>>var value = test();  // value is empty...
>>> 
>>>-- Regards,
>>>Yusuke Suzuki
>>> 
>>>___
>>>es-discuss mailing list
>>>es-discuss@mozilla.org 
>>>https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>> Regards,
>> Yusuke Suzuki
>> 
>> ___
>> 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: Comments on Meeting Notes

[Kevin Smith]

> Of course, you cited only one sentence I wrote and cut the rest where I
> adverted to the problem.


Sorry - I get creative with my cuts sometimes : )


> But is it a real problem?


Probably not, but my POV is that if let is an identifier (and in non-strict
mode, it will be), then let it have all the rights and privileges thereto
pertaining.

It's like `let` is that annoying uncle at your Christmas dinner.  Nobody
wants him there but he's entitled to his egg-nog just like everyone else.
 : )

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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Andrea Giammarchi]

for develoeprs I meant jQuery users too, being one of th emost popular API
out there.

What I meant with jQuery#add method is that last thing added is the one
returned, it does nto return the initial object, it returns the new result
out of a merge but this is not the initial this, this is a new thing with
latest added thing in.

Br


On Tue, Dec 4, 2012 at 11:34 AM, Rick Waldron wrote:

>
>
>
> On Tue, Dec 4, 2012 at 1:55 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> clear for "us" ( Developers ) but also clear semantically speaking.
>>
>> As it is proposed now it looks like if a "setter" returns something which
>> is the context while, again, when you set 99% of the time you don't want to
>> do it separately in order to have that value back.
>>
>> You don't want to create another reference and you want "set" to do what
>> you expect: set
>>
>> When you set, you implicitly point to the set value as it is for:
>>
>> return some.prop = someValue;
>>
>> var setValue = (obj.prop = someValue);
>>
>> var deflt = obj.prop || (obj.prop = value);
>>
>> this.doStuff(
>>   this.hasOwnProperty(key) ?
>> this[key] : this[key] = computateThingOnce()
>> );
>>
>> And so on ... I think there are tons of use cases more frequent and used
>> than this.set(key, value).get(key) ... I wonder how many times you have
>> dreamed about var value = arr.push(some[data]); too
>>
>
> My dream would be that push returned the array, so that I could
> immediately operate on that array.
>
>
>
>> and going back to jQuery style, when you add something, the equivalent of
>> set or add for Set, you point to the subset you have added, not the initial
>> collection, isn't it ...
>> http://api.jquery.com/add/
>>
>
> No, this returns a new jQuery object (ie. the array-like jQuery collection
> of elements) that is the initial object merged with the newly added item
> (pushed onto the end) and filtered for uniqueness:
>
> var elems = jQuery("body");
>
> elems.add("div:first");
> // [ body, div ]
>
> elems.add("div:first");
> // [ body, div ] <-- "looks" the same
>
> The creation of a new jQuery object (via pushStack) is a legacy
> mechanism—however the observable result is effectively the same as
> set.add(something) => set, as elements.add(element) => newElements (as far
> as any web developer's program semantics are concerned).
>
>
>
>>
>>
>>  So developers prefer the added/set value,
>>
>
> Three vocal posters to a mailing list do not represent "developers" as a
> whole. There were more web developer originating committee members that
> supported returning this. (I hate playing this game, it's not fun)
>
>
>
>> this is why I have asked who/why you decided for that, IMHO pointless,
>> `this` as default return.
>>
>
> I answered this directly in the first response. I proposed it, based on a
> wealth of existing library code used on the web and the proposal was met
> with significant support from within the committee.
>
>
>> It just does not look right but sure it might have some use case ... the
>> fact I had to think about them means already these are more rare than a
>> classic returned value.
>>
>> +1 Smalltalk choice then
>>
>
> All due respect, but JavaScript is not Smalltalk. Let's standardize on our
> own established patterns.
>
> Rick
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Meeting Notes

[Brendan Eich]

Kevin Smith wrote:


1JS wants new syntax to be its own opt-in. 



Right - except of course `let[i] = j;` isn't new syntax.


Of course, you cited only one sentence I wrote and cut the rest where I 
adverted to the problem. But is it a real problem?


 In non-strict, `let` is either an identifier, or it isn't.  If it's 
an identifier, then let it be a full-fledged identifier, not some 
half-man, half-beast.  I think it's best to avoid situations where we 
have to say things like "it is, except when it's not".


What if we just say "use let in ES6"? The incompatible change is nasty 
in theory, but in practice it may be a tree falling in a forest.


This is the argument, which you did not engage because you assumed a 
conclusion or just preferred not to have to worry. I sympathize! But the 
position we arrived at does not require assuming anything. 
Implementations and search engines can try this out and see if it bites 
back.


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

Re: How to count the number of symbols in a string?

[David Bruant]

Le 04/12/2012 20:25, Jason Orendorff a écrit :
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens > wrote:


On 30 Nov 2012, at 22:50, Norbert Lindenberg
mailto:ecmascr...@norbertlindenberg.com>> wrote:

> There's nothing in the proposal yet because I intentionally kept
it small. It's always possible to add functionality, but we need
some evidence that it will be widely used.

My guess would be that in 99% of all cases where
`String.prototype.length` is used the intention is to count the
code points, not the UCS-2/UTF-16 code units.


I don't think this is right. My guess is that in most cases where it 
matters either way, the intention is to get a count that's consistent 
with .charAt(), .indexOf(), .slice(), RegExp match.index, and every 
other place where string indexes are used.
I think Twitter has a bug as mentioned earlier in the thread and that's 
unrelated to consistency with the method you're mentioning.
I however agree that if something is added to get the actual length, a 
whole set of methods needs to be added too.


That said, of course this is a sensible feature to add; but calling it 
".realLength" wouldn't help anyone understand the rather fine 
distinction at issue.
Maybe the solution lies in finding the right prefix to define .*length, 
.*charAt(), .*indexOf(), etc. Maybe "CP" for "code points" .CPlength? 
.cpLength/cpCharAt/cpIndexOf... ?


While you're talking about regexps, I think there is an issue with 
current RegExps. Mathias will know better. Could a new flag solve the issue?


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

Re: Comments on Meeting Notes

[Brendan Eich]

David Herman wrote:

In general, I would like to see more updates and more convergence regarding the 
modules specification, as many of us are now aiming at a (seemingly) wildly 
moving target.


Well, the standard isn't out yet, so to some degree this is part of the 
process. But I take the blame for this stuff not happening sooner. I am 
actively working on modules, and trying to nail this all down as soon as 
possible.


I would like to defend Dave against Kevin's "wildly". Sam's writeup from 
the minutes gives the history:


STH: Yes, that was the way, but there was a realization that much of the 
earlier approach was flawed and these updates lead to revisions.


One important use case for modules is to configure module references, so 
that libraries can import jQuery (for example), and get the appropriate 
version of jQuery specified by the page. Further, it's desirable to be 
able to use different code for the same library name in different 
context. Originally, the modules proposal managed this via lexical 
scope, as follows:


module M1 {
  module jquery = "jquery.js";
  module something = "something_that_uses_jquery.js"
}

module M2 {
  module jquery = "zepto.js";
  module something_else = "something_else_that_uses_jquery.js"
}

However, this has two major problems:
Inheriting scope across references to external files is potentially 
confusing, and disliked by a number of people
Once we decided to share instances of the same module, the "parent 
scope" of a module is no longer well-defined


Therefore, we abandoned the idea of inheriting scope across external 
references.  However, this had two consequences that we did not 
immediately appreciate.  First, we no longer had a method for managing 
this configuration between module names and source code.  Second, scoped 
module names no longer had nearly as much use as originally.


Thus, Dave and I revisited the design, abandoning the use of lexical 
scope for managing module names, and introducing module names that could 
be configured on a per-Loader basis.


-

Now, there's no "wildness" here (things too a while, OTOH). The main 
trajectory is from second class modules with lexical scope and no 
memoization of shared instance by MRL, to memoization for sharing, to 
lose the nested lexical scope when modules are not inlined, to more 
manageable module names that actually match existing practice pretty well.


(Oh, and we gave up on lexical-only all the way up, and kept the global 
object as top scope, but (separate from modules _per se_) with a new, 
single lexical contour populated by script elements based on 
let/const/class/module bindings.)


That the default loader knows about pathnames and ".js" is a good thing 
in my view. You want something else, write another loader.


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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Rick Waldron]

On Tue, Dec 4, 2012 at 1:55 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> clear for "us" ( Developers ) but also clear semantically speaking.
>
> As it is proposed now it looks like if a "setter" returns something which
> is the context while, again, when you set 99% of the time you don't want to
> do it separately in order to have that value back.
>
> You don't want to create another reference and you want "set" to do what
> you expect: set
>
> When you set, you implicitly point to the set value as it is for:
>
> return some.prop = someValue;
>
> var setValue = (obj.prop = someValue);
>
> var deflt = obj.prop || (obj.prop = value);
>
> this.doStuff(
>   this.hasOwnProperty(key) ?
> this[key] : this[key] = computateThingOnce()
> );
>
> And so on ... I think there are tons of use cases more frequent and used
> than this.set(key, value).get(key) ... I wonder how many times you have
> dreamed about var value = arr.push(some[data]); too
>

My dream would be that push returned the array, so that I could immediately
operate on that array.



> and going back to jQuery style, when you add something, the equivalent of
> set or add for Set, you point to the subset you have added, not the initial
> collection, isn't it ...
> http://api.jquery.com/add/
>

No, this returns a new jQuery object (ie. the array-like jQuery collection
of elements) that is the initial object merged with the newly added item
(pushed onto the end) and filtered for uniqueness:

var elems = jQuery("body");

elems.add("div:first");
// [ body, div ]

elems.add("div:first");
// [ body, div ] <-- "looks" the same

The creation of a new jQuery object (via pushStack) is a legacy
mechanism—however the observable result is effectively the same as
set.add(something) => set, as elements.add(element) => newElements (as far
as any web developer's program semantics are concerned).



>
>
> So developers prefer the added/set value,
>

Three vocal posters to a mailing list do not represent "developers" as a
whole. There were more web developer originating committee members that
supported returning this. (I hate playing this game, it's not fun)



> this is why I have asked who/why you decided for that, IMHO pointless,
> `this` as default return.
>

I answered this directly in the first response. I proposed it, based on a
wealth of existing library code used on the web and the proposal was met
with significant support from within the committee.


> It just does not look right but sure it might have some use case ... the
> fact I had to think about them means already these are more rare than a
> classic returned value.
>
> +1 Smalltalk choice then
>

All due respect, but JavaScript is not Smalltalk. Let's standardize on our
own established patterns.

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

Re: [[Call]] pass through result completion to callee

[Brendan Eich]

In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also 
13.2.2 [[Construct]], which layers on [[Call]], so [[Call]] is the 
lowest layer single algorithm that has to deal with completions.


Pushing down into FunctionBody is ok if there are no other uses of 
FunctionBody that do not want this common processing, i.e., where 
evaluation does not funnel through [[Call]]. Are there no other such uses?


ES1-5 all handle the cases via something like

4. If result.type is throw then throw result.value.
5. If result.type is return then return result.value.
6. Otherwise result.type must be normal. Return undefined.

in 13.2.1 [[Call]].

Conserving this code under ES6's relocated [[Call]] internal method 
seems best, all else equal.


/be

Yusuke Suzuki wrote:

Thanks.

I've just filed it to bugs.ecmascript.org  
https://bugs.ecmascript.org/show_bug.cgi?id=1119


It appears to me that the best fix is in the evaluation semantics
of FunctionBody.


Looks nice to me too.


On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock 
mailto:al...@wirfs-brock.com>> wrote:


(Note that this is probably the sort of issue that would be better
to report to bugs.ecmascript.org )

Yes, that looks like an issue.  It appears to me that the best fix
is in the evaluation semantics of FunctionBody.  It should take
care of Return completions and also make sure that normal
completions yield undefined and not empty.

Letting Return completions escape from functions was needed when
we were considering supporting block lambdas but isn't need now.

Allen





On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote:


Hello all,

Because of 8.3.19.1 step 17, [[Call]] returns result completion
even if result.type isn't return.
As the result, [[Call]] may return NormalCompletion(empty), is it
expected behavior?
I think we should change empty to undefined.

For example,

function test() {
  var i;
}
var value = test();  // value is empty...

-- 
Regards,

Yusuke Suzuki

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





--
Regards,
Yusuke Suzuki

___
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: Comments on Meeting Notes

[David Herman]

On Dec 4, 2012, at 8:54 AM, Kevin Smith  wrote:

> Particularly worrisome to me is the suggestion that the default loading 
> behavior should map:
> 
> import x from "foo";
> 
> to:
> 
> System.baseURL + "foo" + ".js"
> 
> This is contrary to all url resolution algorithms on the web, and involves 
> way too much magic.

As James says, it's not contrary to AMD, and it's also similar to NPM. And it's 
similar to systems like YUI, but in a slightly different way: instead of the 
nesting structure of modules being expressed as nested objects, it's expressed 
as nested logical names.

This came about as a result of a couple things: First, James raised a concern 
that there's a kind of impedance mismatch between the string/filesystem nesting 
and the dotted sub-module nesting, and it wasn't clear how to decide between 
them, or how the naming of a filesystem structure should map to the naming of 
dot-paths as the result of a build tool.

But second, we realized that the whole initial design of binding module names 
to identifiers (as opposed to string names) no longer solved the problem it was 
initially supposed to solve. An application needs to set up a configuration or 
registry where components can get at other components by some sort of naming 
convention. Originally this was achieved by binding modules to variables that 
were globally accessible and implicitly shared in scope with other modules. 
This was problematic for various reasons and removed, but now it was no longer 
possible to use variables to create a shared registry of the modules in the 
system. And yet, at the same time, the loader *did* contain such a registry.

Finally, this makes for a more straightforward equivalence between modules in 
separate files and modules concatenated together into a single file; they can 
be given names that match the names that would match the logical names that map 
to the filesystem, so the code that uses them doesn't have to change.

> In general, I would like to see more updates and more convergence regarding 
> the modules specification, as many of us are now aiming at a (seemingly) 
> wildly moving target.

Well, the standard isn't out yet, so to some degree this is part of the 
process. But I take the blame for this stuff not happening sooner. I am 
actively working on modules, and trying to nail this all down as soon as 
possible.

Dave

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

Re: (Weak){Set|Map} subclassing

[Allen Wirfs-Brock]

On Dec 4, 2012, at 10:57 AM, Erik Arvidsson wrote:

> 
> On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock  
> wrote:
> 
> 
> If you forget to do the super[create] call you don't get [[Prototype]] 
> initialized.  However, if you leave out that super call you will also not 
> allocate any superclass provided per instance state.   So, it would be buggy 
> anyway.
> 
> I was really hoping this would solve the Array subclass problem. Is this how 
> you imagined it working then?
> 
> Array.@@create = function() {
>   var newObj = [];
>   newObj.__proto__ = this.prototype;
>   return newObj;
> };
> 

This indeed should solve the array subclassing problem.  You code is logically 
what Array.@@create needs to do.  In the spec. it will be expressed as a call 
to an abstraction operation that creates an exotic array object.  That call is 
parameterized with the [[Prototype]] value for the new instance.

Allen

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

Re: Comments on Meeting Notes

[Kevin Smith]

> 1JS wants new syntax to be its own opt-in.


Right - except of course `let[i] = j;` isn't new syntax.  In non-strict,
`let` is either an identifier, or it isn't.  If it's an identifier, then
let it be a full-fledged identifier, not some half-man, half-beast.  I
think it's best to avoid situations where we have to say things like "it
is, except when it's not".

And while I agree that `let` is nice, in my personal experience it's by far
not the most important new feature of ES6.  In fact, for me it ends up way
down on the list behind arrows, classes, object literal shortcuts,
templates, comprehensions, destructuring, modules, const, etc.  It's above
proxies though ; ).  In short, I don't think we need to put quite such a
high priority on `let` adoption.

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

Re: How to count the number of symbols in a string?

[Jason Orendorff]

On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens  wrote:

> On 30 Nov 2012, at 22:50, Norbert Lindenberg <
> ecmascr...@norbertlindenberg.com> wrote:
>
> > There's nothing in the proposal yet because I intentionally kept it
> small. It's always possible to add functionality, but we need some evidence
> that it will be widely used.
>
> My guess would be that in 99% of all cases where `String.prototype.length`
> is used the intention is to count the code points, not the UCS-2/UTF-16
> code units.


I don't think this is right. My guess is that in most cases where it
matters either way, the intention is to get a count that's consistent with
.charAt(), .indexOf(), .slice(), RegExp match.index, and every other place
where string indexes are used.

That said, of course this is a sensible feature to add; but calling it
".realLength" wouldn't help anyone understand the rather fine distinction
at issue.

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

Re: [[Call]] pass through result completion to callee

[Yusuke Suzuki]

Thanks.

I've just filed it to bugs.ecmascript.org
https://bugs.ecmascript.org/show_bug.cgi?id=1119

 It appears to me that the best fix is in the evaluation semantics of
> FunctionBody.


Looks nice to me too.


On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock wrote:

> (Note that this is probably the sort of issue that would be better to
> report to bugs.ecmascript.org)
>
> Yes, that looks like an issue.  It appears to me that the best fix is in
> the evaluation semantics of FunctionBody.  It should take care of Return
> completions and also make sure that normal completions yield undefined and
> not empty.
>
> Letting Return completions escape from functions was needed when we were
> considering supporting block lambdas but isn't need now.
>
> Allen
>
>
>
>
>
> On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote:
>
> Hello all,
>
> Because of 8.3.19.1 step 17, [[Call]] returns result completion even if
> result.type isn't return.
> As the result, [[Call]] may return NormalCompletion(empty), is it expected
> behavior?
> I think we should change empty to undefined.
>
> For example,
>
> function test() {
>   var i;
> }
> var value = test();  // value is empty...
>
> --
> Regards,
> Yusuke Suzuki
>
>  ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>


-- 
Regards,
Yusuke Suzuki
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Brendan Eich]

Allen Wirfs-Brock wrote:

It's less clear which is the best choice for JS.


I have to say I think Mark is on the better track (not to say "only 
right track"). Cascading wants its own special form, e.g., Dave's 
mustache-repurposed proposal at


https://blog.mozilla.org/dherman/2011/12/01/now-thats-a-nice-stache/

so one can write cascades without having to be sure the methods involved 
follow an unchecked |this|-returning convention.


This frees the set return value pigeon-hole to be what many people 
naturally want, from Smalltalk to JS (just citing experience). In the 
meeting, I heard |this|-return asserted as a dominant pattern, but I 
don't believe it is -- especially not for collection.set() methods.


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

Re: (Weak){Set|Map} subclassing

[Erik Arvidsson]

On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock wrote:

>
>
> If you forget to do the super[create] call you don't get [[Prototype]]
> initialized.  However, if you leave out that super call you will also not
> allocate any superclass provided per instance state.   So, it would be
> buggy anyway.
>

I was really hoping this would solve the Array subclass problem. Is this
how you imagined it working then?

Array.@@create = function() {
  var newObj = [];
  newObj.__proto__ = this.prototype;
  return newObj;
};

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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Andrea Giammarchi]

clear for "us" ( Developers ) but also clear semantically speaking.

As it is proposed now it looks like if a "setter" returns something which
is the context while, again, when you set 99% of the time you don't want to
do it separately in order to have that value back.

You don't want to create another reference and you want "set" to do what
you expect: set

When you set, you implicitly point to the set value as it is for:

return some.prop = someValue;

var setValue = (obj.prop = someValue);

var deflt = obj.prop || (obj.prop = value);

this.doStuff(
  this.hasOwnProperty(key) ?
this[key] : this[key] = computateThingOnce()
);

And so on ... I think there are tons of use cases more frequent and used
than this.set(key, value).get(key) ... I wonder how many times you have
dreamed about var value = arr.push(some[data]); too and going back to
jQuery style, when you add something, the equivalent of set or add for Set,
you point to the subset you have added, not the initial collection, isn't
it ...
http://api.jquery.com/add/

So developers prefer the added/set value, this is why I have asked who/why
you decided for that, IMHO pointless, `this` as default return.

It just does not look right but sure it might have some use case ... the
fact I had to think about them means already these are more rare than a
classic returned value.

+1 Smalltalk choice then




On Tue, Dec 4, 2012 at 10:43 AM, Allen Wirfs-Brock wrote:

>
> On Dec 3, 2012, at 2:53 PM, Nathan Wall wrote:
>
> I'm not a person of influence, but as a JS developer, I agree with Andrea
> on this. I think Map#set() should return the value. I would expect the same
> behavior as obj[key] = value. I find Andrea's use case (m.get(k) ||
> m.set(k, v)) more compelling than the method chaining possibilities.
>
>
> It's also worth noting that in Smalltalk  the at:put: methods that roughly
> correspond to ES6 set methods always return the value that is stored. This
> is in a language where the default behavior is to return the "this value"
> of a method.
>
> Smalltalk programmers use "this chaining" a lot, but in the case of
> at:put: the stored value is deemed the more interesting value to return. In
> reality it depends upon your use case.  If you want to do this chaining
> then you want the this value as the result.  If you want to pass a computed
> stored value on to something else, you want the stored value returned.  You
> can't have it both ways.  Smalltalk had another way to do this chaining
> that  ignores the actual return value, so returning the stored value was an
> obvious design choice for it.
>
> It's less clear which is the best choice for JS.
>
> Allen
>
>
>
>
>
>
>
>
>
>
>
> Nathan
>
>
> --
> Date: Mon, 3 Dec 2012 14:21:24 -0800
> Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
> From: andrea.giammar...@gmail.com
> To: waldron.r...@gmail.com
> CC: es-discuss@mozilla.org
>
> IMHO, a set(key, value) should return the value as it is when you address
> a value
>
> var o = m.get(k) || m.set(k, v); // o === v
>
> // equivalent of
>
> var o = m[k] || (m[k] = v); // o === v
>
> a set with a key that returns `this` is a non case so almost as useless as
> the void return is.
>
> Usefulness comes with use cases ... except this jQuery chainability thingy
> that works fine for jQuery structure ( an ArrayLike Collection ) who asked
> for map.set(k0, v0).set(k1, v1).set(k2, v2) ? Or even
> map.set(k0,v0).get(k1) ? what are use cases for this?
>
> I am honestly curious about them because I cannot think a single one ...
> specially with the Set
>
> s.add(k0).add(k1).add(k2) ... this code looks weird inlined like this ...
>
> Thanks for your patience
>
>
>
>
>
>
>
> On Mon, Dec 3, 2012 at 2:04 PM, Rick Waldron 
> wrote:
>
>
>
>
> On Mon, Dec 3, 2012 at 4:28 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
> I wonder what was the use case that convinced TC39 to return `this` with
> these methods.
>
>
> Assuming you read the notes, I proposed the agenda item based on the best
> practice of ensuring meaningful returns, and in the case of mutation
> methods, |this| is a meaningful return.
>
>
> Accordingly, this will never work:
> var query = map.has('queried') ? map.get('queried') :
> map.set('queried', $('myquery'));
>
>
> Previously, map.set() had a useless void return...
>
>
>
> And it will be something like:
> var query = map.has('queried') ? map.get('queried') :
> map.set('queried', $('myquery')).get('queried');
>
> which is ugly and I don't really understand where map.set(k0, v0).set(k1,
> v1).set(k2, v2) could be useful.
>
>
> Accessing the object post-mutation allows for more expressive use of the
> API.
>
>
> Rick
>
>
> Thanks for clarifications ( a use case would be already good )
>
> br
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> ___ es-discuss mai

Re: (Weak){Set|Map} subclassing

[Herby Vojčík]

Allen Wirfs-Brock wrote:

On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:


Allen Wirfs-Brock wrote:



So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is passed as the this value
to @@create
3) Let ctorResult be Foo.[[call]](newObj,args)
4) If Type(ctorResult) is Object, return ctorResult
5) else return newObj

I have just thought about this, and came to similar conclusion, but not
using @@create, but by splitting [[Construct]] into [[Alloc]] and
[[Init]]. My reasoning was more about speccing that [[Init]] is used
instead of [[Call]] in new as well as in super(...). So I don't care if
[[Alloc]] is [[Alloc]] or @@create.

But I did not know whether there is will to respecify [[Construct]]. If
there is, would it be reasonable to define [[Call]] on functions as well
as [[Init]] on constructor functions, as invoke it instead of [[Call]]
in [[Construct]] (and also super(...), but there the [[Call]] is buried
deeper in some abstract operation)? The default [[Init]] is to delegate
to [[Call]], but is potentially different.


super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.

Making the allocation step a regular method call is good because it
eliminates the need to expand the MOP to include an additional
internal method/trap. My assumption here is that it generally better
to do things at the object level than at the meta-object level and
to only use the meta-object level for things that are impossible to
accomplish  using regular objects properties.

It isn't clear to me if there is a general need to distinguish
[[Init]] (ie, called via the new operator) from [[Call]] (ie, called
 any other way). I need to take a close look at the chapter 15
functions that have differed "called as a constructor" and "called
as a function" behaviors in order to see if we can discriminate those
cases some other way


Some of the builtins do that (though it is a weak argument). But drawing 
from their example, one may want to create a class so that new 
Foo(...args) creates and Foo(obj) can do something else, like 
adapt/transform.


I meant [[Init]] not as a spec-only thing for the already existing 
precedents, but to allow user to distinguish [[Call]] and [[Construct]] 
behaviour, like:


class Foo [extends ...] {
  [init]() {  }
  [call]() {  }
  // [create]() {  }
  ...
}

and use [init]/[call] (or __init__/__call__ if the 
do-not-bring-in-computed-name-just-for-iterator mentioned in "Comments 
on Meeting Notes" thread wins) to specify [[Init]] and [[Call]] 
behaviour, with fallbacks to use when only one is present ([init] -> 
[call] if [init] not present; [call] fails with "Initializer only" when 
not present).



===

As a _second_ step / food for thought, not a part of previous proposal,
so please take them separately, thanks, [[Construct]] could be
refactored from internal operation ([[...]]) into abstract spec
operation, and constructor could be tested by presence of [[Init]].


I don't see a major benefit of getting rid of [[Construct]] and
adding [[Init]]. That doesn't reduce the width of the MOP. However,
we've both noted that [[Construct]] could potentially be replaced
with an abstract operation (or just inlined as part of the semantics
of the new operator).


So you know if function is a constructor or not. You need something that 
bears authority for this, and without [[Construct]] it is [[Init]].



The real question is whether there are any existing use cases
(probably in the DOM) that requires intervention prior to the call
to @@create. If so, we need [[Construct]]. If not, we probably could
eliminate it.

A secondary question, if we only have @@create and [[Call]] what is
the IsConstructor test criteria. Or perhaps IsConstructor isn't need
at all. It is new in the ES6 spec. and only has two uses, both of
which  look like they could probably be eliminated.


If they can, fine; but there definitely are non-constructor functions, 
and you should be able to detect if something is a constructor.



Allen


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

Re: Comments on Meeting Notes

[Brendan Eich]

Kevin Smith wrote:
I recommend allowing let declarations only in strict mode.  This is 
the simple, backwards-compatible path.  Strict mode only has a bad 
reputation because, in ES5, it is restrictive-only.  There are 
(almost) no carrots leading users there.


Strict mode has a bad rep for two other important causes:

* It forks runtime semantics, which requires careful testing in 
pre-ES5-strict implementations. This has been a real-world problem, 
multiple times.


* It deoptimizes, e.g. a strict-mode function must be optimized to copy 
actual parameter values into arguments if it could use the arguments object.


 Leave non-strict as is, and let users opt-in to "let".  An excellent 
carrot.


The problem is precisely that users cannot opt into "let" alone by its 
novel syntax. Opting into strict mode may or may not win but it has 
added costs and benefits, and that means let adoption will suffer.


1JS wants new syntax to be its own opt-in. The only issue with making 
let work in non-strict code is the obscure let[i] = j; pattern. If no 
one actually wrote such code (it's possible; public web searches by big 
search-engine companies, or at least one so far, found nothing), then we 
should not risk reduced let adoption by yoking it to the heavier burden 
of strict mode.


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

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Allen Wirfs-Brock]

On Dec 3, 2012, at 2:53 PM, Nathan Wall wrote:

> I'm not a person of influence, but as a JS developer, I agree with Andrea on 
> this. I think Map#set() should return the value. I would expect the same 
> behavior as obj[key] = value. I find Andrea's use case (m.get(k) || m.set(k, 
> v)) more compelling than the method chaining possibilities.
> 

It's also worth noting that in Smalltalk  the at:put: methods that roughly 
correspond to ES6 set methods always return the value that is stored. This is 
in a language where the default behavior is to return the "this value" of a 
method.  

Smalltalk programmers use "this chaining" a lot, but in the case of at:put: the 
stored value is deemed the more interesting value to return. In reality it 
depends upon your use case.  If you want to do this chaining then you want the 
this value as the result.  If you want to pass a computed stored value on to 
something else, you want the stored value returned.  You can't have it both 
ways.  Smalltalk had another way to do this chaining that  ignores the actual 
return value, so returning the stored value was an obvious design choice for it.

It's less clear which is the best choice for JS.

Allen










> 
> Nathan
> 
> 
> Date: Mon, 3 Dec 2012 14:21:24 -0800
> Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
> From: andrea.giammar...@gmail.com
> To: waldron.r...@gmail.com
> CC: es-discuss@mozilla.org
> 
> IMHO, a set(key, value) should return the value as it is when you address a 
> value
> 
> var o = m.get(k) || m.set(k, v); // o === v
> 
> // equivalent of
> 
> var o = m[k] || (m[k] = v); // o === v
> 
> a set with a key that returns `this` is a non case so almost as useless as 
> the void return is.
> 
> Usefulness comes with use cases ... except this jQuery chainability thingy 
> that works fine for jQuery structure ( an ArrayLike Collection ) who asked 
> for map.set(k0, v0).set(k1, v1).set(k2, v2) ? Or even map.set(k0,v0).get(k1) 
> ? what are use cases for this?
> 
> I am honestly curious about them because I cannot think a single one ... 
> specially with the Set
> 
> s.add(k0).add(k1).add(k2) ... this code looks weird inlined like this ...
> 
> Thanks for your patience
> 
> 
> 
> 
> 
> 
> 
> On Mon, Dec 3, 2012 at 2:04 PM, Rick Waldron  wrote:
> 
> 
> 
> On Mon, Dec 3, 2012 at 4:28 PM, Andrea Giammarchi 
>  wrote:
> I wonder what was the use case that convinced TC39 to return `this` with 
> these methods.
> 
> Assuming you read the notes, I proposed the agenda item based on the best 
> practice of ensuring meaningful returns, and in the case of mutation methods, 
> |this| is a meaningful return.
> 
> 
> Accordingly, this will never work:
> var query = map.has('queried') ? map.get('queried') : map.set('queried', 
> $('myquery'));
> 
> Previously, map.set() had a useless void return...
> 
> 
> 
> And it will be something like:
> var query = map.has('queried') ? map.get('queried') : map.set('queried', 
> $('myquery')).get('queried');
> 
> which is ugly and I don't really understand where map.set(k0, v0).set(k1, 
> v1).set(k2, v2) could be useful.
> 
> Accessing the object post-mutation allows for more expressive use of the API.
> 
> 
> Rick
> 
> 
> Thanks for clarifications ( a use case would be already good )
> 
> br
> 
> ___
> 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
> ___
> 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: [[Call]] pass through result completion to callee

[Allen Wirfs-Brock]

(Note that this is probably the sort of issue that would be better to report to 
bugs.ecmascript.org)

Yes, that looks like an issue.  It appears to me that the best fix is in the 
evaluation semantics of FunctionBody.  It should take care of Return 
completions and also make sure that normal completions yield undefined and not 
empty.

Letting Return completions escape from functions was needed when we were 
considering supporting block lambdas but isn't need now.

Allen





On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote:

> Hello all,
> 
> Because of 8.3.19.1 step 17, [[Call]] returns result completion even if 
> result.type isn't return.
> As the result, [[Call]] may return NormalCompletion(empty), is it expected 
> behavior?
> I think we should change empty to undefined.
> 
> For example,
> 
> function test() {
>   var i;
> }
> var value = test();  // value is empty...
> 
> -- 
> Regards,
> Yusuke Suzuki
> 
> ___
> 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: Comments on Meeting Notes

[James Burke]

On Tue, Dec 4, 2012 at 8:54 AM, Kevin Smith  wrote:
> === Modules ===
>
> Perhaps I'm misreading the notes, but I am concerned about the amount of
> churn that I'm seeing in module discussions.  Particularly worrisome to me
> is the suggestion that the default loading behavior should map:
>
> import x from "foo";
>
> to:
>
> System.baseURL + "foo" + ".js"
>
> This is contrary to all url resolution algorithms on the web, and involves
> way too much magic.

[sorry Kevin, sent this to you directly when meant to sent to list, so
sending again]

This is what AMD loaders use. For me, it seems straightforward, not
much magic on its own. The old dojo one did too, except it used dots
instead of slashes in IDs, but it was effectively baseUrl + id +
'.js'. I believe it has held up well.

What other ID-to-URL resolution algorithms are used on the web that
have decent adoption, besides just plain URLs? Alternatively, what
problems do you see with that algorithm?

It is important to use an ID type vs a plain URL to allow sharing of
code between environments that may have different path resolution
logic. For example, for node, it may choose to check a few file paths
for a given ID. For networked loading though it is good to have a
reasonable one IO lookup rule per ID.

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

Re: lexical 'super' in arrow functions?

[Allen Wirfs-Brock]

There is a long history of people publishing annotated versions of language 
standards that add informative materials.  The Ecma copyright even explicitly 
allows for this. 

I think I've said before that there is an opportunity here for somebody to run 
with this idea for ECMAScript. You don't even need to have TC39 involved.  (But 
there probably are T39 members, like Rick,  who may want to contribute or even 
take the lead.)

Allen

On Dec 4, 2012, at 8:26 AM, Rick Waldron wrote:

> 
> On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:
> 
>> Language specification is a difficult task, especially when handling a 
>> complex language, legacy spec style, and wide variety of audience 
>> background, not to mention a committee with lots of feedback and opinions.  
>> We are very lucky that Allen does the job he does.
>> 
>> That also means we shouldn't make it harder, or ask the spec to bear burdens 
>> it doesn't need to handle.  JavaScript is blessed with numerous excellent 
>> books describing how to use the language and what various features are for, 
>> including Dave's new book. That's the place to go for description and 
>> explanation, not the spec.
>> 
>> Sam
>> 
> Agreed. Community members that care enough to know about and stay up to date 
> with ES6 progress could work together with TC39 to create something similar 
> to http://dmitrysoshnikov.com/ecmascript/es5-chapter-0-introduction/ 
> 
> Anyone interested in working on something like this should contact me at this 
> email address
> 
> Rick
>  
>> ___
>> 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

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

Re: (Weak){Set|Map} subclassing

[Allen Wirfs-Brock]

On Dec 4, 2012, at 7:21 AM, Erik Arvidsson wrote:

> Is there a missing step in that outlined algorithm? Where is [[Prototype]] 
> set?
> 
> So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
> 1) Let creator be Foo.[[Get]](@@create)
> 2 ) Let newObj be creator.call(foo).  //Foo is passed as the this value to 
> @@create
> 
> 2.5) Call newObj.[[SetInheritance]](Foo.prototype)
> 
> 3)  Let ctorResult be Foo.[[call]](newObj,args)
> 4)  If Type(ctorResult) is Object, return ctorResult
> 5) else return newObj

I do it in @@create:

> The definition of the Function.prototype.@@create would be loosely
> 
> function() {
> return Object.create(this.prototype);
> }


The this.prototype access gets the "prototype" property value from the leaf 
constructor ( in the example, Foo) and Object.create sets it upon creation.

I'm a bit reluctant to separate object allocation from initializing 
[[Prototype]] as I suspect that in many cases implementations will want to do 
these as an atomic step and separating them would be visible, via a Proxy.

On the other hand, requiring @@create to explicitly take care of setting 
[[Prototype]] maybe a bit of a foot gun.

Ideally, any @@create method that is just adding private state to an ordinary 
object should be coded as:

Foo.assign({
   //class methods of Foo
   [create] () {
  let newObj = super[create]();   //eventually calls 
Function.prototype.@@create.  We really need to allow super in obj lits to 
support this
  newObj[myPrivate] = undefined
  return newObj
   }
});

If you forget to do the super[create] call you don't get [[Prototype]] 
initialized.  However, if you leave out that super call you will also not 
allocate any superclass provided per instance state.   So, it would be buggy 
anyway. 

Allen



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

Re: (Weak){Set|Map} subclassing

[Allen Wirfs-Brock]

On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:

> Allen Wirfs-Brock wrote:
>> 
>> 
> >
> > So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
> > 1) Let creator be Foo.[[Get]](@@create)
> > 2 ) Let newObj be creator.call(foo). //Foo is passed as the this value
> > to @@create
> > 3) Let ctorResult be Foo.[[call]](newObj,args)
> > 4) If Type(ctorResult) is Object, return ctorResult
> > 5) else return newObj
> 
> I have just thought about this, and came to similar conclusion, but not
> using @@create, but by splitting [[Construct]] into [[Alloc]] and
> [[Init]]. My reasoning was more about speccing that [[Init]] is used
> instead of [[Call]] in new as well as in super(...). So I don't care if
> [[Alloc]] is [[Alloc]] or @@create.
> 
> But I did not know whether there is will to respecify [[Construct]]. If
> there is, would it be reasonable to define [[Call]] on functions as well
> as [[Init]] on constructor functions, as invoke it instead of [[Call]]
> in [[Construct]] (and also super(...), but there the [[Call]] is buried
> deeper in some abstract operation)? The default [[Init]] is to delegate
> to [[Call]], but is potentially different.

super(...) is just shorthand for super.constructor(...) (when it occurs in a 
constructor) so it is just a use of [[Call]]. No magic.

Making the allocation step a regular method call is good because it eliminates 
the need to expand the MOP to include an additional internal method/trap.  My 
assumption here is that it generally better to do things at the object level 
than at the meta-object level and to only use the meta-object level for things 
that are impossible to accomplish using regular objects properties. 

It isn't clear to me if there is a general need to distinguish [[Init]] (ie, 
called via the new operator) from [[Call]]  (ie, called any other way).  I need 
to take a close look at the chapter 15 functions that have differed "called as 
a constructor" and "called as a function" behaviors in order to see if we can 
discriminate those cases some other way 

> 
> ===
> 
> As a _second_ step / food for thought, not a part of previous proposal,
> so please take them separately, thanks, [[Construct]] could be
> refactored from internal operation ([[...]]) into abstract spec
> operation, and constructor could be tested by presence of [[Init]].

I don't see a major benefit of getting rid of [[Construct]] and adding 
[[Init]].  That doesn't reduce the width of the MOP.  However, we've both noted 
that [[Construct]] could potentially be replaced with an abstract operation (or 
just inlined as part of the semantics of the new operator). 

The real question is whether there are any existing use cases (probably in the 
DOM) that requires intervention prior to the call to @@create.  If so, we need 
[[Construct]].  If not, we probably could eliminate it.

A secondary question, if we only have @@create and [[Call]] what is the 
IsConstructor test criteria.  Or perhaps IsConstructor isn't need at all.  It 
is new in the ES6 spec. and only has two uses, both of which look like they 
could probably be eliminated.

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

Re: Comments on Meeting Notes

[Herby Vojčík]

Kevin Smith wrote:

=== @names ===

I think punting on @name syntax until ES7 is a wise move.  I would like
to sneak in a word of clarification on my modular @name proposal,
though.  In my proposal, @names are not "implicitly declared" variables.
  They are namespaced identifiers, where the namespace container is the
module URL.  They are static in the sense that all @names can be mapped
to a globally unique string (module URL + identifier) prior to execution.

Modular @names are not simply veneer over symbols.  They provide a
separate facility (non-conflicting property names) which happens to use
unique symbols as an implementation strategy.  It could perhaps also use
globally unique strings...

In my opinion, we should not go with bracketed, computed property names
*solely* for the support of the iterator protocol.  Ultimately, I would

+1

recommend a more conservative approach for ES6:  use the plain string
"iterator" as the protocol hook.  Once the syntactic issues have been


I'd say not "iterator". This is a special identifier, so to speak 
"instead-of-symbol-internal-name", so I would go for __iterator__. Same 
for other few examples which may have benefited from symbols but cannot.


It would create consistent __legacy__ realm where each member should be 
obsoleted by evangelizing the right way once it appears (__proto__ won't 
have one, it is too stuck; __{define|lookup}{Getter|Setter}__ already 
have the right way; it can be same for __iterator__, __create__, 
__hasInstance__ etc.).



addressed in ES7, future language hooks can use unique symbols.  Give
the user base some time to digest symbols, and see where the cows roam
before adding syntax directing them.  There is more than enough new
"stuff" in ES6, without having to rewrite everything in terms of symbols
(just yet).

=== let ===

I recommend allowing let declarations only in strict mode.  This is the
simple, backwards-compatible path.  Strict mode only has a bad
reputation because, in ES5, it is restrictive-only.  There are (almost)
no carrots leading users there.  Leave non-strict as is, and let users
opt-in to "let".  An excellent carrot.


I would agree. But there would be a fight of what else should only be 
strict-mode, since it is simpler to do it that way. Then there comes 
1JS, and refactoring concerns, and a lot more, probably.



- Kevin


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

Comments on Meeting Notes

[Kevin Smith]

=== @names ===

I think punting on @name syntax until ES7 is a wise move.  I would like to
sneak in a word of clarification on my modular @name proposal, though.  In
my proposal, @names are not "implicitly declared" variables.  They are
namespaced identifiers, where the namespace container is the module URL.
 They are static in the sense that all @names can be mapped to a globally
unique string (module URL + identifier) prior to execution.

Modular @names are not simply veneer over symbols.  They provide a separate
facility (non-conflicting property names) which happens to use unique
symbols as an implementation strategy.  It could perhaps also use globally
unique strings...

In my opinion, we should not go with bracketed, computed property names
*solely* for the support of the iterator protocol.  Ultimately, I would
recommend a more conservative approach for ES6:  use the plain string
"iterator" as the protocol hook.  Once the syntactic issues have been
addressed in ES7, future language hooks can use unique symbols.  Give the
user base some time to digest symbols, and see where the cows roam before
adding syntax directing them.  There is more than enough new "stuff" in
ES6, without having to rewrite everything in terms of symbols (just yet).

=== let ===

I recommend allowing let declarations only in strict mode.  This is the
simple, backwards-compatible path.  Strict mode only has a bad reputation
because, in ES5, it is restrictive-only.  There are (almost) no carrots
leading users there.  Leave non-strict as is, and let users opt-in to
"let".  An excellent carrot.

=== Modules ===

Perhaps I'm misreading the notes, but I am concerned about the amount of
churn that I'm seeing in module discussions.  Particularly worrisome to me
is the suggestion that the default loading behavior should map:

import x from "foo";

to:

System.baseURL + "foo" + ".js"

This is contrary to all url resolution algorithms on the web, and involves
way too much magic.

In general, I would like to see more updates and more convergence regarding
the modules specification, as many of us are now aiming at a (seemingly)
wildly moving target.

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

Re: lexical 'super' in arrow functions?

[Rick Waldron]

On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:

> Language specification is a difficult task, especially when handling a 
> complex language, legacy spec style, and wide variety of audience background, 
> not to mention a committee with lots of feedback and opinions.  We are very 
> lucky that Allen does the job he does.
> That also means we shouldn't make it harder, or ask the spec to bear burdens 
> it doesn't need to handle.  JavaScript is blessed with numerous excellent 
> books describing how to use the language and what various features are for, 
> including Dave's new book. That's the place to go for description and 
> explanation, not the spec.
> Sam
> 
> 

Agreed. Community members that care enough to know about and stay up to date 
with ES6 progress could work together with TC39 to create something similar to 
http://dmitrysoshnikov.com/ecmascript/es5-chapter-0-introduction/ 

Anyone interested in working on something like this should contact me at this 
email address

Rick
 
> ___
> 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: On dropping @names

[Brendan Eich]

Andreas Rossberg wrote:

Indeed. (Although I don't think we have implicit let-scopes in JS.)


Only in comprehensions and generator expressions, which have an explicit 
outer syntax.


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

Re: lexical 'super' in arrow functions?

[Brendan Eich]

Herby Vojčík wrote:
WHY / WHAT / HOW sections (with only HOW being normative)? 


I've said it before: ECMA-357 (E4X) tried this and all it did was make 
more bug habitat in the informative sections, and confuse implementors 
who treated prose as normative and took its differences not as bugs, but 
as truth (either ignoring the normative spec pseudo-code, or thinking it 
wrong).


As Sam said, a spec cannot serve two masters. Pedagogy and more advanced 
studies require other tools. The first job of the spec is to normatively 
specify the language for implementors.


I look forward to Brandon's super-cross-referencing work!

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

Re: lexical 'super' in arrow functions?

[Herby Vojčík]

Claus Reinke wrote:

Like everyone else on this list, I have grown familiar with the current
spec - not as familiar as tc39 members, but enough to find answers
to questions when I need them.

But with the evolving drafts of the new spec, I'm back in the situation
most JS coders are wrt the spec: trying to find answers in the spec is
just a little demoralizing, often unsuccessful, and will remain a hidden
art for those who do not read/study most of it at some point.

Language specs, for those languages that have them, fall somewhere
on a scale from informal, readable to formal, unreadable.

ES, for all its faults, has a spec on the formal side -which is a very
good thing!- but unfortunately also on the not directly readable side.

The reason is that the spec is essentially a reference implementation -
even though it doesn't use a formal language, it consists of "what to
do with this piece of code" instructions. Understanding these
instructions requires knowledge and understanding of the reference
machine code patterns, instructions and system libraries.

This makes the spec not so useful for quick lookups or for
understanding what those language features are for.

It would enhance the usefulness of this important asset -the spec-
if each section would start with one or two informal paragraphs
on the most salient points of each feature.

The formal parts would still be there to confirm the details, to guide
implementers, and as the normative part of the spec. But the informal
parts would make quick lookups succeed, would give guidance on
what is being formalized, and would support program construction
("what is this good for?" rather than just "how do I implement this?").


WHY / WHAT / HOW sections (with only HOW being normative)?


Claus


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

Re: (Weak){Set|Map} subclassing

[Erik Arvidsson]

Is there a missing step in that outlined algorithm? Where is [[Prototype]]
set?

So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo).  //Foo is passed as the this value to
@@create

2.5) Call newObj.[[SetInheritance]](Foo.prototype)

3)  Let ctorResult be Foo.[[call]](newObj,args)
4)  If Type(ctorResult) is Object, return ctorResult
5) else return newObj



On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock wrote:

>
> On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
>
> On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock 
> wrote:
>
>> The simplification I've thought about is eliminating [[Construct]] as an
>> internal method/Proxy trap and just making the call @@Create/call
>> consturctor sequence the evaluation semantics of the new operator.  But
>> I've not yet convinced myself that this is sufficient to capture all of the
>> "called as constructor"/"called as a function" semantic silliness that some
>> chapter 15 built-ins have. I'm also not sure that DOM and friends don't
>> have other dependencies on a reified [[Construt]]
>>
>
> The simplification I had in mind was changing [[Construct]] from an
> internal method/Proxy trap to an ordinary .@@construct method. There would
> be a @@construct/constructor split rather than a
> [[Construct]]/@@create/constructor split.
>
> But on reflection, it didn't seem like that would be simpler in practice.
> Having two separately hookable phases of object construction is just right.
> A class can easily customize either behavior in a way that not only works,
> but will still work when the class is subclassed further.
>
> -j
>
>
> OK, so it sounds like we have a plan. I'll update the spec. to use
> @@create.
>
> Allen
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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

Re: (Weak){Set|Map} subclassing

[Erik Arvidsson]

On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock wrote:

>
> OK, so it sounds like we have a plan. I'll update the spec. to use
> @@create.
>

Thanks for resolving this. Having the class side inheritance for @@create
makes complete sense to me and it solves a lot of issues. It can be used to
explain how subclassing Array and DOM objects work too.

For example:

HTMLButtonElement.@@create = function() {
  return document.createElement('button');
};

class MyButton extends HTMLButtonElement {
  constructor(text) {
this.textContent = text;
  }
}

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

Re: On dropping @names

[Andreas Rossberg]

On 4 December 2012 14:28, Claus Reinke  wrote:
> Could you please document the current state of concerns, pros and
> cons that have emerged from your discussions so far? You don't
> want to have to search for these useful clarifications when this topic
> comes up again (be it in tc39 or in ES6 users asking "where is private?").

There were various mixed concerns, like perhaps requiring implicit
scoping of @-names to be practical in classes, their operational
generativity perhaps being a mismatch with their seemingly static
meaning in certain syntactic forms, potential ambiguities with what @x
actually denotes in certain contexts. And probably more. Most of that
should be in the meeting minutes.

> Implicit scoping in a language with nested scopes has never been a
> good idea (even the implicit var/let scopes in JS are not its strongest
> point). Prolog got away with it because it had a flat program structure
> in the beginning, and even that fell down when integrating Prolog-like
> languages into functional one, or when adding local sets of answers.

Indeed. (Although I don't think we have implicit let-scopes in JS.)

> This leaves the "generativity" concerns - I assume they refer to
> "gensym"-style interpretations? ES5 already has gensym, in the
> form of Object References (eg, Object.create(null)), and Maps
> will allow to use those as keys, right?
>
> The only thing keeping us from using objects as property names
> is the conversion to strings, and allowing Name objects as property
> names is still on the table (as is the dual approach of using a
> WeakMap as private key representation, putting the object in the
> key instead of the key in the object).

Symbols will definitely still be usable as property names, that's
their main purpose.

The main technical reason that arbitrary objects cannot be used indeed
is backwards compatibility. The main moral reason is that using
general objects only for their identity seems like overkill, and you
want to have a more targeted and lightweight feature.

> So I'm not sure how your concerns are being addressed by
> merely replacing a declarative scoping construct by an explicitly
> imperative gensym construct?

We have the gensym construct anyway, @-names were intended to be
merely syntactic sugar on top of that.

> There is a long history of declarative interpretations of gensym-
> like constructs, starting with declarative accounts of logic variables,
> over name calculi (often as nu- or lambda/nu-calculi, with greek
> letter nu for "new names"), all the way to pi-calculi (where names
> are communication channels between processes). Some of these
> calculi support name equality, some support other name features.
>
> The main steps towards a non-imperative account tend to be:
>
> - explicit scopes (this is the difference to gensym)
> - scope extrusion (this is the difference to lambda scoping)

Scope extrusion semantics actually is equivalent to an allocation
semantics. The only difference is that the store is part of your term
syntax instead of being a separate runtime environment, but it does
not actually make it more declarative in any deeper technical sense.
Name generation is still an impure effect, albeit a benign one.

Likewise, scoped name bindings are equivalent to a gensym operator
when names are first-class objects anyway (which they are in
JavaScript).

> As Brendon mentions, nu-scoped variables aren't all that different
> from lambda-scoped variables. It's just that most implementations
> do not support computations under a lambda binder, so lambda
> variables do not appear to be dynamic constructs to most people,
> while nu binders rely on computations under the binders, so a
> static-only view is too limited.

I think you are confusing something. All the classical name calculi
like pi-calculus or nu-calculus don't reduce/extrude name binders
under abstraction either.

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

Re: (Weak){Set|Map} subclassing

[Herby Vojčík]

Allen Wirfs-Brock wrote:


On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:


On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock
mailto:al...@wirfs-brock.com>> wrote:

The simplification I've thought about is eliminating [[Construct]]
as an internal method/Proxy trap and just making the call
@@Create/call consturctor sequence the evaluation semantics of the
new operator. But I've not yet convinced myself that this is
sufficient to capture all of the "called as constructor"/"called
as a function" semantic silliness that some chapter 15 built-ins
have. I'm also not sure that DOM and friends don't have other
dependencies on a reified [[Construt]]


The simplification I had in mind was changing [[Construct]] from an
internal method/Proxy trap to an ordinary .@@construct method. There
would be a @@construct/constructor split rather than a
[[Construct]]/@@create/constructor split.

But on reflection, it didn't seem like that would be simpler in
practice. Having two separately hookable phases of object construction
is just right. A class can easily customize either behavior in a way
that not only works, but will still work when the class is subclassed
further.

-j


OK, so it sounds like we have a plan. I'll update the spec. to use @@create.


Maybe it has been lost somewhere 
(https://mail.mozilla.org/pipermail/es-discuss/2012-December/026757.html), 
but I'd like to propose a little bit around call vs. init separation, 
that fits into this restructuting, copying older post here:


> Overall, I like this approach. However, I don't think @@create belongs
> on the prototype object. This make the @@create functionality for a
> particular kind of object available to anyone who gets their hands on an
> instance object of the class. This smells like a capability leak.
>
> Instead, I would make @@create a property of the actual constructor
> function and I would place the default @@create on Function.prototype,
> which all functions inherit from.
>
> So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
> 1) Let creator be Foo.[[Get]](@@create)
> 2 ) Let newObj be creator.call(foo). //Foo is passed as the this value
> to @@create
> 3) Let ctorResult be Foo.[[call]](newObj,args)
> 4) If Type(ctorResult) is Object, return ctorResult
> 5) else return newObj

I have just thought about this, and came to similar conclusion, but not
using @@create, but by splitting [[Construct]] into [[Alloc]] and
[[Init]]. My reasoning was more about speccing that [[Init]] is used
instead of [[Call]] in new as well as in super(...). So I don't care if
[[Alloc]] is [[Alloc]] or @@create.

But I did not know whether there is will to respecify [[Construct]]. If
there is, would it be reasonable to define [[Call]] on functions as well
as [[Init]] on constructor functions, as invoke it instead of [[Call]]
in [[Construct]] (and also super(...), but there the [[Call]] is buried
deeper in some abstract operation)? The default [[Init]] is to delegate
to [[Call]], but is potentially different.

===

As a _second_ step / food for thought, not a part of previous proposal,
so please take them separately, thanks, [[Construct]] could be
refactored from internal operation ([[...]]) into abstract spec
operation, and constructor could be tested by presence of [[Init]].

> The definition of the Function.prototype.@@create would be loosely
>
> function() {
> return Object.create(this.prototype);
> }
>
> Allen

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

Re: lexical 'super' in arrow functions?

[Sam Tobin-Hochstadt]

On Dec 4, 2012 4:59 AM, "Claus Reinke"  wrote:

> ES, for all its faults, has a spec on the formal side -which is a very
> good thing!- but unfortunately also on the not directly readable side.
>
> The reason is that the spec is essentially a reference implementation -
> even though it doesn't use a formal language, it consists of "what to
> do with this piece of code" instructions. Understanding these
> instructions requires knowledge and understanding of the reference
> machine code patterns, instructions and system libraries.
>
> This makes the spec not so useful for quick lookups or for
> understanding what those language features are for.
>
> It would enhance the usefulness of this important asset -the spec-
> if each section would start with one or two informal paragraphs
> on the most salient points of each feature.
>
> The formal parts would still be there to confirm the details, to guide
> implementers, and as the normative part of the spec. But the informal
> parts would make quick lookups succeed, would give guidance on
> what is being formalized, and would support program construction
> ("what is this good for?" rather than just "how do I implement this?").

Language specification is a difficult task, especially when handling a
complex language, legacy spec style, and wide variety of audience
background, not to mention a committee with lots of feedback and opinions.
We are very lucky that Allen does the job he does.

That also means we shouldn't make it harder, or ask the spec to bear
burdens it doesn't need to handle.  JavaScript is blessed with numerous
excellent books describing how to use the language and what various
features are for, including Dave's new book. That's the place to go for
description and explanation, not the spec.

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

Re: On dropping @names

[Claus Reinke]

Recall the main objection was not the generativity of @names mixed with the obj.@foo pun 
(after-dot). It was the usability tax of having to declare


 private @foo;

before defining/assiging

 obj.@foo = foo;

(in a constructor, typically).


Good clarification, thanks. Yes, the more important issue is the tension between having to 
predeclare all the @names in a scope and the danger of implicit scoping. (That said, the 
generativity does worry me. It's a smell.)


| Just to be super-sure we grok one another, it's not the generativity by
| itself (since nested function declarations are the same, as I mentioned
| in the meeting). It is the generativity combined with the obj.@foo pun
| on Good Old obj.foo where 'foo' is a singleton identifier equated to a
| string property name. Right?

Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far? You don't
want to have to search for these useful clarifications when this topic
comes up again (be it in tc39 or in ES6 users asking "where is private?").

Implicit scoping in a language with nested scopes has never been a
good idea (even the implicit var/let scopes in JS are not its strongest
point). Prolog got away with it because it had a flat program structure
in the beginning, and even that fell down when integrating Prolog-like
languages into functional one, or when adding local sets of answers.

So starting with explicit scoping, adding shortcuts if necessary
(and only after careful consideration), seems the obvious route
suggested by language design history.

This leaves the "generativity" concerns - I assume they refer to
"gensym"-style interpretations? ES5 already has gensym, in the
form of Object References (eg, Object.create(null)), and Maps
will allow to use those as keys, right?

The only thing keeping us from using objects as property names
is the conversion to strings, and allowing Name objects as property
names is still on the table (as is the dual approach of using a
WeakMap as private key representation, putting the object in the
key instead of the key in the object).

So I'm not sure how your concerns are being addressed by
merely replacing a declarative scoping construct by an explicitly
imperative gensym construct?

There is a long history of declarative interpretations of gensym-
like constructs, starting with declarative accounts of logic variables,
over name calculi (often as nu- or lambda/nu-calculi, with greek
letter nu for "new names"), all the way to pi-calculi (where names
are communication channels between processes). Some of these
calculi support name equality, some support other name features.

The main steps towards a non-imperative account tend to be:

- explicit scopes (this is the difference to gensym)
- scope extrusion (this is the difference to lambda scoping)

the former allows to put limits on who can mention/co-create a
name in a program, the latter allows to pass names around, once
created. With gensym, there is only one creator, all sharing comes
from passing the symbol around while expanding its scope (think:
"do { private @name; @name }").

As Brendon mentions, nu-scoped variables aren't all that different
from lambda-scoped variables. It's just that most implementations
do not support computations under a lambda binder, so lambda
variables do not appear to be dynamic constructs to most people,
while nu binders rely on computations under the binders, so a
static-only view is too limited.

I'm not saying that @names are necessary or have the best
form already - just that I would like to understand the concerns
and how they are addressed by the decisions made.

Claus


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

Re: lexical 'super' in arrow functions?

[Brandon Benvie]

That's related to a feature I have on my list to implement:
cross-referencing actions in a step-through debugger/action record with
their specific origin in the spec. So as you step into a function, see a
sidebar scrolling by with Function Declaration Instantiation, multiple hits
on Create(Mutable|Immutable)Binding, InstantiateArgumentsObject, Binding
Initialization, etc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: lexical 'super' in arrow functions?

[Claus Reinke]

Is 'super' currently limited to method bodies, excluding local functions?
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm this from the spec.


Yes, clearly super should be able to be used in an arrow function that is lexically scoped to an 
enclosing super binding.  The mechanism for describing this are mostly in the spec., but I just 
checked and there are a few loose ends that I will clean-up in the next spec. draft.


That would be good.


OK, I looked more closely and anything needed for super references within from within Arrow 
functions is already in the current draft.  Just trace through the algorithms in section 11.2.4. 
Particularly, steps 1-4 of the Evaluation algorithms.  However, I did add a few clarifying note in 
the next draft.


Before I make another attempt to extract this info from the current
draft, let me some general comments:

Like everyone else on this list, I have grown familiar with the current
spec - not as familiar as tc39 members, but enough to find answers
to questions when I need them.

But with the evolving drafts of the new spec, I'm back in the situation
most JS coders are wrt the spec: trying to find answers in the spec is
just a little demoralizing, often unsuccessful, and will remain a hidden
art for those who do not read/study most of it at some point.

Language specs, for those languages that have them, fall somewhere
on a scale from informal, readable to formal, unreadable.

ES, for all its faults, has a spec on the formal side -which is a very
good thing!- but unfortunately also on the not directly readable side.

The reason is that the spec is essentially a reference implementation -
even though it doesn't use a formal language, it consists of "what to
do with this piece of code" instructions. Understanding these
instructions requires knowledge and understanding of the reference
machine code patterns, instructions and system libraries.

This makes the spec not so useful for quick lookups or for
understanding what those language features are for.

It would enhance the usefulness of this important asset -the spec-
if each section would start with one or two informal paragraphs
on the most salient points of each feature.

The formal parts would still be there to confirm the details, to guide
implementers, and as the normative part of the spec. But the informal
parts would make quick lookups succeed, would give guidance on
what is being formalized, and would support program construction
("what is this good for?" rather than just "how do I implement this?").

Claus


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