Re: Proposal: Additional Meta Properties for ES7

I think the fact you had to write two solutions where one attach to the object the listener and another one needs a double arrow (rainbow) already shows we have a hole in the language once covered by arguments.callee. just to make sure we are not misunderstanding each other: I wrote two solution

Re: Proposal: Additional Meta Properties for ES7

> nope, you are limiting your object to have only one listener per event, I think that's not quite how reality is. You gonna lose that listeners next time somebody use same name with the same object. true. For cases where that isn't enough, i assume you're thinking of canceling from within the han

Re: Proposal: Additional Meta Properties for ES7

and yet you haven't removed any anonymous arrow listener. Assign first? Mostly nobody will do that, it's just less natural then `obj.on(something, ()=>happening)` personally? Yes, I tend to assign listeners somewhere, at least when I intend to remove them later. I've even been known to assign t

Re: Proposal: Additional Meta Properties for ES7

For concise methods, the problem is already solved by 'this', isn't it? ({f(n){return n>1?n*this.f(n-1):1}}.f)(6) 720 No, not for the general case. You could have arrived here via a 'super' method call in which case 'this.f' will take you back to a subclass' f rather then recurring on thi

Re: Proposal: Additional Meta Properties for ES7

Can you show an example of how callee is used with a fat arrow function? ((n)=>n>1? n*function.callee(n-1) : 1) meta-level tools are powerful, which makes them ever so tempting. They are too powerful to be used for tasks for which current language-level tools are sufficient. Using a call-by-v

Re: Reserving await within Arrow Functions

1) ... functions "express" mappings 2) Generators "express" sequences 3) Don't muddy the waters If only!-( In current ES6 design, functions are mixed with generators (probably based on the notion that the generator function call is suspended, even though, in reality, generator functions return

Re: Generator Arrow Functions

What I don't understand is why generator expressions are not used as the only way to create generators, leaving 'function' alone. We have been over this before: to support flows that for-of loops cannot expression, specifically coroutine libraries such as http://taskjs.org/. Which is why I ke

Re: Weak callbacks?

I mean the promises-unwrapping proposal that has now been accepted into ES6 and the DOM, and IIUC is being implemented by several browser makers. Let's call these JS Promises. The unwrapping means that there is forced recursive synchronization, doesn't it? When trying to work with nested promi

Re: Generator Arrow Functions

Everybody should probably review esdiscuss.org/topic/why-do-generator-expressions-return-generators where we discussed this before. which suggests using generator expressions as arrow bodies to make generator functions with arrows () => (for (y of gen) y) What I don't understand is why gene

function .name property in draft spec?

According to  http://wiki.ecmascript.org/doku.php?id=harmony:function_name_property , "This proposal has progressed to the Draft ECMAScript 6 Specification". I can't seem to find it in "6th Edition / Draft September 27, 2013", though. Claus ___ es-discu

Re: Clarification on function default param values

Generally variables are brought into scope by an explicitly appearing defining occurrence. Two exceptions are the "function" brings into scope both "this" and "arguments". These remain in scope until shadowed by a nested "function" or by an explicit definition. Note that "this" can never be explic

Re: 'function *' is not mandatory

I am one of those on TC39 that want the visible flag. Since, in my view, the only non-mistaken need to preserve sloppy mode is as an ES3 compatibility mode and ES3 has no generators, I consider this flagging issue to be the important one. Yes, you have to read the function to know *what* it genera

es-discuss@mozilla.org

languages that use imperative iterators, like Python and PHP. And JS -- JS has mutation and objects. It's not going to swerve toward Haskell (sorry, Claus). I never understood your automated dislike of Haskell. You misread me pretty badly here. Why? Your dislike of Haskell as a reference/mo

es-discuss@mozilla.org

languages that use imperative iterators, like Python and PHP. And JS -- JS has mutation and objects. It's not going to swerve toward Haskell (sorry, Claus). I never understood your automated dislike of Haskell. But if you are speaking for tc39 when claiming that JS has no aspirations towards

Re: generators vs forEach

I have no idea why both you and Brendan assert that I was arguing/ rehashing for deep delimited continuations (let alone call/cc). Because you wrote: "1 can be worked around, but not with the usual tools of function definitions and calls - "yield" forces use of "function*" and "yield*"

es-discuss@mozilla.org

I do not understand why (1) iterators are specified using a self-updating API when a functional API would seem preferable, or why (2) generators are linked to functions, when block-level generators would seem to be sufficient and less complex. In some more detail: 1. Why do iterators have an i

Re: generators vs forEach

2 generators do not compose as freely as iteration functions, because they are tied to special syntax and restricted contexts You place blame on generators here, but beside the laments about deep coroutines -- totally understandable, but Brendan is right that that they are pointless -- your e

Re: generators vs forEach

And why not? Because yield is a statement Yield is an expression. Thanks for the correction. Yes, "yield expr" is an expression, syntactically. It doesn't have the nice composition and code transformation properties that I usually associate with expressions, it imposes unusual restrictions

Re: Chained comparisons from Python and CoffeeScript

I'd like to see this implemented, at least for greater/less than (-or equal to). a < b < c a <= b <= c Desugars to a < b && b < c a <= b && b <= c As a workaround, consider that ES6 arrow functions are going to make something like this readable: function sortedBy(op,...args) {

Re: generators vs forEach

// this doesn't work function* generator(){ [1,2,3].forEach( function(x){ yield x } ) } I have been thinking and with for..of, I can't find a good reason to use .forEach instead of for..of. for..of does what you need here with generators too. Perhaps you're right that .forEach

Re: generators vs forEach

// this doesn't work function* generator(){ [1,2,3].forEach( function(x){ yield x } ) } I have been thinking and with for..of, I can't find a good reason to use .forEach instead of for..of. for..of does what you need here with generators too. I've been looking at this example

Re: generators vs forEach

// this doesn't work function* generator(){ [1,2,3].forEach( function(x){ yield x } ) } This would make generators deep, violating the non-interleaving assumptions of intermediate callers on the call stack. This is why we accepted generators only on condition that they be shallow

generators vs forEach

[prompted by this nodejs list thread "Weird error with generators (using suspend or galaxy)" https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4 ] 1. higher order functions are used to model control structures 2. generators/yield are designed to allow for suspend/resume of control str

Re: Why is .bind so slow?

Thanks, kg! Your message represents the kind of discussion/information I was hoping for. If your hunch as to the reason is correct, it would seem an easy target for optimization. Partially and efficiently emulating arrow functions in ES6 transpilers should be a strong argument in favor, though n

Why is .bind so slow?

The TypeScript project tries to emulate arrow functions through the "_this = this" pattern and keeps running into corner cases where a semi-naïve renaming is not sufficient. I have been trying to suggest using .bind to emulate arrow functions instead, but the counter-arguments are (a) .bind might

Re: [proposal] Function calls, syntax sugar

function f(a, b) { return [a, b]; } Currently: f(1, 2); // [1, 2] Whereas... // single parameter, implicit arguments pseudo-array: f(1, 2); |a| would be magically be treated like a ...rest param that wasn't really an array, but instead a implicit arguments pseudo-array? // [[1, 2],

Re: Maps and Sets, goodbye polyfill ?!

In general, generators are very hard to polyfill. (Not impossible, as you can do a CPS transform of the source code, but very difficult.) It depends on what you want. For concise specification of iteration, you can do something without full CPS transform, by using monadic coding style. My scrat

Re: [proposal] Function calls, syntax sugar

A slightly less ambitious suggestion: consider f() as syntax for the implicit arguments array (which, as of ES6, can be considered deprecated), then make the parens in this syntax optional In other words, you could write f 1 // single parameter f(1,2)// single parameter, im

Re: [module] dynaimic namespace/scope

Why allow global scope to leak into a new module? That would require a tedious preamble for pretty much any bit of code you want to write. We agree, that's why we haven't tried to do this. You could have a standard preamble, implicitly included, with an option to override. That way, everythi

Re: Creating your own errors

```javascript function CustomError(message) { this.message = message || ''; } CustomError.prototype = new Error; // whenever you need throw new CustomError; ``` At best, this will not preserve the stack trace property, at worse this will lead to a bad one. Because the location info will b

Re: Where'd Promise#done go?

< https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/makeQ.js> supports promise pipelining in user land, using the makeRemote and makeFar extension points. Hmm. If you are moving JS code (from the callbacks) to another site, some local references (including some t

Re: Where'd Promise#done go?

x.a().then( t1p=> y.b().then( t2p=> let t3p = { then(cb) { t1p.then( t1=> t2p.then( t2=> t1.c(t2).then( t3=> cb(t3) ) ) ) }; ...' ) ) (where ...' is ..., transformed to work with a promise t3p instead of t3) Now, waiting for the .a and .b roundt

Re: Where'd Promise#done go?

Naively translating the standard pipeline example gives x.a().then( t1=> y.b().then( t2=> t1.c(t2).then( t3=> ... ) ) ) .. This is naïve because the synchronous method calls should really be asynchronous message sends. If we assume local proxies that forward local method calls to remo

Re: Where'd Promise#done go?

I'm worried that you may be suffering from and spreading a terminology confusion. "Promise pipelining" is an important latency reduction optimization when using promises over a network. See Chapter 16 of . Using .then, either with or without the

Re: Conflicts using export *

I am confused: I thought "import *" was removed because, in the presence of dynamically configured loaders, it would leave tools (and programmers) unable to infer the local scope without executing code. Now we have the same issue back via "export *", just need a re-exporting intermediate module?

Re: Conflicts using export *

This is a static error. On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith wrote: Take the following situation: // M.js export * from "foo"; export * from "bar"; I am confused: I thought "import *" was removed because, in the presence of dynamically configured loaders, it would leave t

Re: do we have a thisclass? (for abstract static methods)

We do have this/super for references along the instance prototype chain, and we have this.constructor for getting to the class of an instance method. But what about getting the current class from a static method, for class-side inheritance? Can't you just use "this"? Exactly, that should work.

do we have a thisclass? (for abstract static methods)

We do have this/super for references along the instance prototype chain, and we have this.constructor for getting to the class of an instance method. But what about getting the current class from a static method, for class-side inheritance? // abstract class Super { static f(x) { .g(x

Re: The Paradox of Partial Parametricity

The fact that we can make it monadic is just a bonus; any time you see "monad" just think "container++" - it's just a proven useful bit of structure on top which makes it easy to work with the values inside the container. (It's a bit more abstract than that, of course, but thinking in terms of co

Re: Module naming and declarations

I'm still trying to make sense of the conflicting module naming design goals and usage consequences. You seem to believe otherwise, but I think you still need to explain how any of the above cases is not sufficiently (or even superiorly) supported by lexical modules + the loader API. The most

Re: Module naming and declarations

My biggest concern is that people will assume a certain structure of the module path. Then they will assume that relative paths and logical names can be used interchangeably. E.g. if I'm inside of package "a/b.js" I can access a top level package using either "../backbone.js" or "backbone". I may

Re: Module naming and declarations

A possible alternative might be to switch defaults, using generic relative syntax (:) to keep the two uses apart while avoiding having to introduce a new scheme import $ from "http:jquery"; // it's a URL, don't mess with it import $ from "jquery"; // it's a logical name, do your thing A

Re: Module naming and declarations

[sorry if you saw an earlier empty message - unknown keycombo!-(] That is not my position. My position has always been that if you want "logical names", then a reasonable way to do that is via a scheme: import $ from "package:jquery"; A possible alternative might be to switch defaults, us

Re: Module naming and declarations

That is not my position. My position has always been that if you want "logical names", then a reasonable way to do that is via a scheme: import $ from "package:jquery"; A possible alternative would be to switch the defaults ___ es-discuss mailing

Re: Promise/Future: asynchrony in 'then'

That part I wouldn't be so sure about: in all monads, the .of equivalent is effect-free (in an IO monad, it does no IO; in a non-determinism monad, it is deterministic; in a failure/exception monad, it does not fail; in a count-steps monad, it doesn't count). If you look at those identity laws at

Re: Module naming and declarations

0. No effort: modules are loaded relative to the document base url, with ".js" appended. So `import "jquery"` maps to the relative URL "jquery.js". 2. A few lines: you can use System.ondemand() to set the URL for each module you use. If you call `System.ondemand({"https://example.com/jquery-1.9.1

Re: Promise/Future: asynchrony in 'then'

Promise.of(value).then(cb) = cb(value) promise.then(Promise.of) = promise My interpretation of these laws for promises is that attaching a callback to a resolved promise should execute that callback synchronously (though the callback itself may create an asynchronous promise, introducing i

Re: Promise/Future: asynchrony in 'then'

Thanks for the various references and explanations - it took me a while to follow them. So, while discussion is still ongoing on the details (both of how to spec and what to spec), all specs seem to agree on trying to force asynchrony, and on doing something in 'then' to achieve this. I suspec

Promise/Future: asynchrony in 'then'

The promises-aplus spec has a note that confuses me https://github.com/promises-aplus/promises-spec#notes 1. In practical terms, an implementation must use a mechanism such as setTimeout, setImmediate, or process.nextTick to ensure that onFulfilled and onRejected are not invoked in

Re: Module naming and declarations

users are going to rewrite their code bases twice just because modules are going to be delivered in two stages? What are you talking about? People are not going to rewrite more than once. Current NPM/AMD modules do not nest, so there's no basis for asserting they'll be rewritten twice, first

Re: Module naming and declarations

You argue for a two-level system of non-lexical names to support configuration - okay. But why does that imply you have to drop the lexical naming altogether, instead of using a three-level system (from external to internal to lexical names)? You don't, it's an orthogonal concern. Note that Sam

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

Can you point to any code in wide use that makes use of this "thenables = monads" idea you seem to be implicitly assuming? Perhaps some of this "generic thenable library code"? I have never seen such code, whereas the use of "thenable" to mean "object with a then method, which we will try to tre

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted nesting Perhaps you didn't read my post then?

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

A Future for a Future seems like a corner case compared to the broader simplicity of an implicit unwrap. The argument is not about whether Future> is a common case. The Argument is that Future<...> and Array<...> and Optional<...> and things that may raise catchable errors and other types have

Re: Module naming and declarations

Module names play a role in three processes, in general: 1. As a way to identify local components. 2. As a way to find the physical resource that is the source code (or object code) of the module. 3. As a way for two separately developed components to coordinate about which module they mean. In

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I'm still wading through the various issue tracker threads, but only two concrete rationales for flattening nested Promises have emerged so far: 1 "library author doesn't want nested Promises." 2 crossing Promise library boundaries can create unwanted nesting There is little to be said about 1,

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

I think we see a correlation -- not a 1.0 correlation, but something. Those who've actually used promise libraries with this flattening property find it pleasant. Those who come from either a statically typed or monadic perspective, or have had no experience with flattening promises, generally thi

Re: Futures (was: Request for JSON-LD API review)

Now, instead of a ducktest for a `then` method the promise check would instead be specified as `instanceof Promise`. Picking a message at random for an interjection, there is something that seems to be missing in this discussion: *Promises are only one kind of thenables (the asynchronous th

Re: Modules: Curly Free

But then you went too far and made that entry-point, which with anonymous export is often (but not always) a function, with the body of the module, its top-level code. I suggested that modules be callable, executing the module body and returning what would be the anonymous export. I did not sug

Re: Modules: Curly Free

Anonymous export is simply about allowing library authors to indicate a module's main entry point. Semantically, we're talking about the difference between a string and a symbol; syntactically, we're talking about one production. It's all cleanly layered on top of the rest of the system. Let's

Re: Coordination

But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and

Re: Coordination (was: ES6 Modules)

The "DOM side" should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that "should

Re: Module Execution Order

1) Just to be explicit, this is a different execution order than node/CommonJS modules. Nothing wrong with that, just pointing it out. Yes. Execute-in-order-of-import is used in practice to emulate parameterized modules (for instance, set a global config, *then* import RequireJS). As long a

Re: On Scope And Prototype Security

var public = (function(){ var private = { }; return Object.freeze( Object.create(private) ); }()); // why I cannot avoid this? I'd **LOVE** to! Object.getPrototypeOf(public).test = 123; alert(public.test); // 123 At first, I thought you were right - __proto__ is an object property, so th

Re: Self-recursion and arrow functions

I understand, but it's still a limitation of arrow functions that they rely on arguments.callee to self-reference. Relying on the defined name they're assigned to suffers from the "can be redefined" problem. NFE's don't suffer this problem and can completely avoid `arguments` in ES6 for all use ca

Re: Questions/issues regarding generators

How about lifting the result, to separate yielded objects and end iteration signalling? { yields: obj }// iteration yields obj {} // iteration ends Yes, that would be the proper encoding of an Option/Maybe type, which in the abstract is the ideal (the end object might carry a return v

Re: Questions/issues regarding generators

But, in order to (hopefully) let Brandon calm down a bit, I am NOT making yet another proposal for a two-method protocol. Instead I propose simply _delivering_ a sentinel object as end-of-iteration marker instead of _throwing_ one. The zip function above would then be written as: function zip(it

Re: Transitioning to strict mode

For the ES5 semantics of the interaction of the global scope and the global object, how could you make this a static error? What would you statically test? Would you statically reject the following program, where is itself just some valid expression computing a value (that might be the string "fo

Re: Transitioning to strict mode

You still need more than statement or branch coverage. Otherwise, we might get 100% "coverage" while missing edge cases function raise() { "use strict"; if( Math.random()>0.5 || (Math.random()<0.5) && (variable = 0)) console.log(true); else console.log(false); } r

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)

I'd be interested to see your alternative design suggestion (or, in fact, any more general approach to the issue at hand that would fit into ES). From ES4, http://wiki.ecmascript.org/doku.php?id=proposals:static_generics. Thanks for the pointer. However, I'd like to have even more generic met

Re: Transitioning to strict mode

Out of curiosity, what does your favorite test coverage tool report for the source below? And what does it report when you comment out the directive? :-p Ok, there are exceptions if your code depends on semantic changes described in the third section of the article (dynamic this/eval/arguments).

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

as a "high-integrity" function: var freeze = Object.freeze, push = Function.prototype.call.bind(Array.prototype.push); function makeTable() { var array = []; return freeze({ add: function(v) { push(array, v); }, store: function(i, v) { array[i >>> 0] =

Re: Transitioning to strict mode

Talking about 100% coverage and "catching all errors" is never a good combination - even if you should have found an example of where this works, it will be an exception. There are a couple of things I'm sure of. For instance, direct eval aside (eval needs some specific work anyway because its

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)

More immediately relevant for this thread, I would like to see Array < Container with map, from, filter, and perhaps some others, moving from Array to Container. Then Map and Set would be Containers, supporting operations currently limited to Array This is not gonna happen for several rea

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)

I'd say that either we properly clean up the Array hierarchy, or we leave it alone. A half-baked solution that only applies to typed arrays, and divorces them from the Array hierarchy, seems less attractive than just doing the naive thing, i.e., TypedArray< Array. Agree with that, and I'll go f

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

[to limit the length of my reply, I had to avoid responding to every detail, trying to answer the gist of your message instead; please let me know if I missed anything important] Of course, you might argue that I could just call it like: NodeList.from( [ "div", "span", "p" ].map(nodeName =>

Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

Thanks for the explanations and additional details. Let me first try to rephrase, to see whether I've understood your reasoning: The problem comes from the partial integration of types in ES, specifically having typed arrays but no easy way to express and control the types of the functions map

Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting Notes)

I am trying to understand the discussion and resolution of 'The Array Subclassing "Kind" Issue'. The issue (though not its solution) seemed simple enough class V extends Array { ... } m = (new V()).map(val => val); console.log( m instanceof V ); // false :( and I was expecting solutions

Modules spec procedure suggestion (Re: Jan 31 TC39 Meeting Notes)

There has been a great deal of pressure from users wanting details about whether the modules spec will cover their use cases, from module library authors wanting to determine whether their most important features will be covered (so that they can retire their systems), and -more recently- from tra

Re: Ducks, Rabbits, and Privacy

It's my opinion that saying that closures should be used for an object to hold onto private data, as you are advocating, is in conflict with ES's prototypal model of inheritance. Methods cannot both (A) be on a constructor's prototype and (B) live inside the scope used to house private data. The

Re: Proxy target as __proto__? (Re: Proxy's optional target)

Hi Tom, I'm not sure I fully understand your proposal, but could you not achieve it by simply doing: var target = ...; // might be frozen var p = Proxy( Object.create(target), handler); Ah, too obvious for me, thanks! Also, proxy wrappers often modify functions, which tend to be on a non-f

Proxy target as __proto__? (Re: Proxy's optional target)

The proxy target is important because it specifies some invariants about the proxy (typeof, builtin brand, behavior of forwarding for unspecified traps, values of internal properties like [[DateValue]], [[NumberValue]], etc.). That is probably the most important difference between direct proxi

Re: Private Slots

It's really none of your business when you try to freeze my object whether any of (a) pre-existing private-symbol-named properties remain writable; (b) weakmap-encoded private state remains writable; (c) objects-as-closures environment variables remain writable. Really. Not. Your (user). Busine

Re: Private Slots

I have suggested before that it would be good to put control over object iteration into the hands of the object authors, by enabling them to override the slot iteration method. I might be missing something, but isn't this basically covered with the enumerable flag? There are several object i

Re: Private Slots

Below is a slight variation of the closure "hack" that allows using private properties through this. The idea is to use the public 'this' as prototype for the private 'this', using 'bind' to give instance methods access to the private 'this' Bound methods. Smart! I come to wonder why you even nee

Re: Private Slots

It's really none of your business when you try to freeze my object whether any of (a) pre-existing private-symbol-named properties remain writable; (b) weakmap-encoded private state remains writable; (c) objects-as-closures environment variables remain writable. Really. Not. Your (user). Busine

Re: Private Slots

From the teachability perspective, I'm tired of explaining the closure hack to explain "private" properties. Even to some who are experienced webdevs, I have to explain that they can't access the "private" property through "this.". The language needs to evolve to the point where people can wri

Re: excluding features from sloppy mode

Another thought: What will JavaScript code look like once 99% of browsers in use support ES6? Will we have a language with coherent semantics and a simple structure? That is: is there a way to drop some of the trickiness, long term? And which of the approaches gets us there? In the short term, w

Re: excluding features from sloppy mode

It would actually be nice to have that as a feature: If the variable name is `_` then it can be used multiple times. It’s a nice, self-descriptive way of saying that you don’t care about a parameter value. That underscore wildcard is the exact syntax used in functional languages, and very useful

Re: excluding features from sloppy mode

Ease of teaching != successfully imparted knowledge at scale. Sorry, but it's true. People don't use "use strict"; at top level enough, and teaching them all will take time. Even then, because of the Law of Least Effort, it'll be left out. This is the major objection some of us keep raising, a

Re: Do Anonymous Exports Solve the Backwards Compatibility Problem?

* The module loader API exposes a "runtime" API that is not new syntax, just an API. From some earlier Module Loader API drafts, I thought it was something like System.get() to get a dependency, System.set() to set the value that will be used as the export. * Base libraries that need to live in c

Re: Bringing ES6 to programmers as soon as possible

http://www.2ality.com/2012/12/es6-workflow.html I would really like to see a shared resource collecting ES6 shims and techniques. Since this involves checking those shims against the evolving spec, it would be good to have this as a wiki page moderated by tc39 (otherwise we'll keep seeing new b

Re: lexical 'super' in arrow functions?

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

Re: Do we really need the [[HasOwnProperty]] internal method andhasOwn trap

Also "compile-time garbage collection" or "compile-time memory management". Then there is the whole area of "linear types" or "uniqueness types", "affine types" which allow for in-place updating (reusing memory) without observable side-effects when absence of other references can be proven s

Re: On dropping @names

let lhs = rhs; statements // non-recursive, scope is statements let { declarations }; statements// recursive, scope is // declarations and statements let { // group of mutually recursive bindings, *no stateme

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

If one thing this is clear from this discussion, it is that different programmers have different preferences (perhaps even changeable depending on use case). So, no single standard API will suit everyone and the language support for different patterns could be improved. Meanwhile, it seems one ca

Re: On dropping @names

I was hoping for something roughly like let lhs = rhs; statements // non-recursive, scope is statements let { declarations }; statements// recursive, scope is declarations and statements Problem is that you need mutual recursion between different binding forms, not just '

Re: On dropping @names

I would have preferred if let had not been modeled after var so much, but that is another topic. It is as clean as it can get given JS. I was hoping for something roughly like let lhs = rhs; statements // non-recursive, scope is statements let { declarations }; statements

Re: Module Comments

Well, the thing is it isn't consistent with the destructuring meaning: dropping the curlies here means extracting a single export (aka property), which is not what it means in destructuring assignment/binding anywhere else. But that said, the convenience may well still trump the inconsistency.

Re: On dropping @names

There were various mixed concerns, like perhaps requiring implicit scoping of @-names to be practical in classes, Like implicitly scoping this, super, and arguments, this would cause problems with nested scopes. Unless the name of the class was made part of the implicitly named scope reference?

  1   2   3   4   >