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
For concise methods, the problem is already solved by 'this',
isn't it?
({f(n){return n1?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
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
Can you show an example of how callee is used with a fat arrow function?
((n)=n1? 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
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
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
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
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
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
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-discuss
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 explicitly
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
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
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*
for
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
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
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
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
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) {
// 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
// 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
// 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
[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
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,
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
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],
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
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
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,
```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
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 roundtrips
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
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
http://erights.org/talks/thesis/markm-thesis.pdf. Using .then, either
with or without the
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 remote
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?
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) {
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.
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
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
A possible alternative might be to switch defaults, using generic
relative syntax (scheme:relative) 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
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
[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, using
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.js:
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
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
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
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
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
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 FutureFuture... is a common
case. The Argument is that Future... and Array... and Optional...
and things that may raise catchable errors and other types
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?
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 treat as
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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);
}
raise();
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
someExpression is itself just some valid expression computing a value
(that might be
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
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
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] = v;
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
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
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
[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 =
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
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
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
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.
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
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
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).
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
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 need
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).
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 write
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,
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
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,
* 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
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
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
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
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
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
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.
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
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
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.
Yes. That doesn't mean he should
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
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
1 - 100 of 302 matches
Mail list logo
