On 29 November 2014 at 22:30, Mark S. Miller erig...@google.com wrote:
On Fri, Nov 28, 2014 at 4:21 AM, Andreas Rossberg rossb...@google.com wrote:
[...]
With a normal ephemeral weak map implementation, like the one in V8,
the value in a (map,key,value) triple can be reclaimed _immediately_
On 27 November 2014 at 19:40, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 27, 2014, at 1:17 AM, Andreas Rossberg wrote:
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear in particular, it
seems to assume
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear in particular, it
seems to assume that this representation does not normally need the
ability to iterate (internally) over the keys of a weak map. AFAICT,
that is incorrect.
WeakMap
)
https://github.com/WebReflection/es6-collections#the-weakmap-is-not-weak--and-why
On Thu, Nov 27, 2014 at 9:17 AM, Andreas Rossberg rossb...@google.com
wrote:
The discussion here still makes various untested assumptions about the
transposed representation. With respect to .clear
On 27 November 2014 at 15:58, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
On Thu, Nov 27, 2014 at 2:44 PM, Andreas Rossberg rossb...@google.com
wrote:
Well, there is no functionally correct polyfill for WeakMaps that is
actually weak, regardless of .clear.
Please bear with me so I
On 17 November 2014 17:29, Alex Kocharin a...@kocharin.ru wrote:
17.11.2014, 03:07, “Biju” bijumaill...@gmail.com:
I wish, I could write elegant two of the code pattern I use frequently.
[...]
Patten 2.
I do like to code functions with early exit, like
function someValidationProcess(){
On 13 November 2014 12:25, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
well, Proxy can be a diabolic beast
```js
Object.setPrototypeOf(
Object.prototype,
new Proxy(Object.prototype, evilPlan)
)
```
having no way to understand if an object is a Proxy looks like a footgun to
On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
My opinion is that array testing is fundamental to core JS and is
worth the exception.
This change would only make sense if we also were to special-case all
other places in the spec that currently say if O is an exotic Array
On 31 October 2014 16:40, Katelyn Gadd k...@luminance.org wrote:
I'd also like to chime in since this is a real problem for
performance-sensitive JSIL code:
The idea that JS runtimes will just optimize all our
performance-sensitive loops is lovely. It also appears to be a
fantasy, because
On 29 October 2014 22:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 29, 2014, at 4:13 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
Don't forget the implications for the future. If declaring certain
names in top level scopes is an error if they are also present in the
global
On 29 October 2014 21:59, Mark S. Miller erig...@google.com wrote:
On Wed, Oct 29, 2014 at 8:16 AM, Andreas Rossberg rossb...@google.com
wrote:
On 27 October 2014 16:50, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-10-27 15:00 GMT+01:00 Andreas Rossberg rossb...@google.com:
but without
On 29 October 2014 02:48, Isiah Meadows impinb...@gmail.com wrote:
I'm proposing simply initializing a new instance and GC'ing the old
instance entirely (updating the `this` to point to the new) instead of
the current algorithm of maintaining a list of keys. I know that it
potentially slow
On 28 October 2014 17:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Also I'll check if it's feasible to make it a runtime error for a global let
to shadow a non configurable property of the global object.
Is there a reason why we cannot make it an error for any present
property? Maybe
On 28 October 2014 23:22, Jeff Walden jwalden...@mit.edu wrote:
On 10/28/2014 09:10 AM, Andreas Rossberg wrote:
If so, how do we fix this? Allowing shadowing after the fact is pretty
bad, since it will probably make all accesses to builtin globals
slower in ES6. But it is particularly bad
On 27 October 2014 16:50, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-10-27 15:00 GMT+01:00 Andreas Rossberg rossb...@google.com:
but without breaking membrane transparency.
I'm still not sure I understand how this affects membranes
specifically. A membrane would never pass a proxied
On 27 October 2014 17:45, Mark S. Miller erig...@google.com wrote:
On Mon, Oct 27, 2014 at 7:00 AM, Andreas Rossberg rossb...@google.com
wrote:
On Wed, Oct 22, 2014 at 2:26 PM, Mark Miller erig...@gmail.com wrote:
[...] When the WeakMap is known to necessarily live longer than its
keys
While polishing some remaining corners of lexical scoping support in
V8, we stumbled over the following.
ES5 has the invariant that any identifier not found on the scope chain
_has to be_ a property of the global object (except in the presence of
'with' or sloppy direct eval), or be a reference
On 24 October 2014 22:13, Mark S. Miller erig...@google.com wrote:
On Fri, Oct 24, 2014 at 4:19 AM, Andreas Rossberg rossb...@google.com
wrote:
On 22 October 2014 16:45, Mark S. Miller erig...@google.com wrote:
On Tue, Oct 21, 2014 at 11:59 PM, Andreas Rossberg rossb...@google.com
wrote
On 21 October 2014 22:31, Mark S. Miller erig...@google.com wrote:
in saying that [weak maps] are not designed to work efficiently in that
manner.
Actually, they are. The problem is that initial implementations date from
before we appreciated the need for the transposed representation. The
On 22 October 2014 14:18, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
FWIW the Multiple WeakMaps approach seems to be 2X ( Chrome ) up to 3X ( FF
Nightly ) faster than single WeakMap approach but I don't know how much
WeakMap instances cost in terms of GC operations so this bench might
On 5 October 2014 17:51, Brian Di Palma off...@gmail.com wrote:
1) I think you mean that a parser wants to fail quickly if it comes
across an identifier that was not previously declared as an import but
that could be declared as one deeper in the module file? The simple
solution to that
On 8 October 2014 14:11, Brian Di Palma off...@gmail.com wrote:
I didn't realize how limited in power these fast parsers actually
were, they are basically lexers.
No, that's not correct. They have to perform a full syntax check. That
does not imply binding analysis, though, which is usually
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do lazy
parsing of functions is not going to report static errors before doing a
full parse of the function.
Well, it is no harder than reporting reference
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script.
script
use strict;
function f(value) { x = value; }
On 2 October 2014 09:24, Andreas Rossberg rossb...@google.com wrote:
On 1 October 2014 20:32, Jason Orendorff jason.orendo...@gmail.com wrote:
I think there is a way that the error could occur at runtime even in
all-strict-mode code: when a new const is added at toplevel in a
second script
On 2 October 2014 10:45, Mark Miller erig...@gmail.com wrote:
On Thu, Oct 2, 2014 at 12:22 AM, Andreas Rossberg rossb...@google.com
wrote:
On 1 October 2014 16:09, Erik Arvidsson erik.arvids...@gmail.com wrote:
The static error is problematic. I'm pretty sure that engines that do
lazy
On 2 October 2014 16:06, Andreas Rossberg rossb...@google.com wrote:
So, yes, please let us remove the requirement to make const
assignments an early error. A single, relatively unimportant
diagnostics like that is not worth the considerable complication for
VMs, especially given that all
On 2 October 2014 17:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I believe that the module champions have always wanted static unresolvablse
reference rejection to be part of the module semantics. But we've never had
actual specification for that semantics.
Yes, I had always hoped
On 30 September 2014 22:38, David Herman dher...@mozilla.com wrote:
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote:
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com
wrote:
I just realized this has an unfortunate implication for REPLs. Suppose
On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
That's why, IIRC (haven't checked lately), TCO is only specified for calls
from non-sloppy functions.
PTC (Proper Tail Calls), not TCO. It's confusing to equate the two, from
what I know (corrections
Boris' point seems to be -- and I agree -- that such a test would only
be a semi-decision procedure. I.e., it can only falsify, but not
validate the property for the test program.
/Andreas
On 30 September 2014 04:48, Brendan Eich bren...@mozilla.org wrote:
Put it in a worker or node.js. The
On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote:
I just realized this has an unfortunate implication for REPLs. Suppose
you make this typo:
js let x = Math.cso(a)// oops, TypeError, should be Math.cos
Now x is irreparably hosed in your REPL. That seems
On 30 September 2014 16:31, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Tue, Sep 30, 2014 at 6:56 AM, Andreas Rossberg rossb...@google.com wrote:
On 29 September 2014 19:25, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
That's why, IIRC (haven't checked lately), TCO
On 28 September 2014 20:34, Michał Wadas michalwa...@gmail.com wrote:
We have Object.observe (asynchronous callback whenever object
properties changes), but do we need Function.observe (asynchronous
callback whenever function is called)?
Cons:
- can prevent many optimizations (but
On 28 September 2014 17:01, Marius Gundersen gunder...@gmail.com wrote:
The stacktrace should probably be an array of objects with the properties
`filename`, `function`, `line` and `column`.
Just to be clear, since you said array of objects: 'function' would
still have to be string-valued, to
On 29 September 2014 18:06, Filip Pizlo fpi...@apple.com wrote:
- JS is a great language; it actually lets you write an honest loop. You
don’t *need* tail calls.
Let me repeat what I just wrote in my previous mail: I think not
enough people appreciate the (substantial) difference between
On 29 September 2014 16:55, John Lenz concavel...@gmail.com wrote:
On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com wrote:
On Sep 27, 2014, at 10:15 PM, John Lenz concavel...@gmail.com wrote:
I would like to get see stack traces standardized for ES7, to that end,
I would
On 17 September 2014 19:24, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/17/14, 1:15 PM, Andreas Rossberg wrote:
In the light of that, I'm stilling missing the
compelling reason to introduce new^ at all.
Say you have:
class A extends B {
constructor() {
this = new super
On 15 September 2014 19:20, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
Want to safe the colon for type annotations.:)
Someone building a compile-to-JS language (not LLJS) pointed out to me what
LLJS already did: C-style `type declarator` annotations
On 17 September 2014 19:04, Brendan Eich bren...@mozilla.org wrote:
I agree with Domenic that any derived-class constructor that needs to
allocate with specific arguments *and* that must distinguish new'ing from
calling should have to write an if-else. That's a hard case, EIBTI, etc.
I agree.
On 15 September 2014 06:24, Brendan Eich bren...@mozilla.org wrote:
In the C++ family (Andreas is right, there's a history and lineage to
consider), the special head form may require you to keep it simple and put
any such conditioning in the base class, or an intermediary. This doesn't
bite
On 12 September 2014 17:18, Mark S. Miller erig...@google.com wrote:
Even when written explicitly, either by an IDE or a human, the
constructor(a, b, c) {
this = new super(...arguments);
...
}
pattern is usually bad. It is fine in a certain special case I mention
below. It would
where
people pass redundant arguments to functions -- _that_ is bad
practice. The language shouldn't default to that practice itself.
On Sep 12, 2014, at 8:26 AM, Andreas Rossberg wrote:
I think it's fine to have a default new super call, but only with an
empty argument list. That would also
On 10 September 2014 16:45, Erik Arvidsson erik.arvids...@gmail.com wrote:
For or loops are spec'ed to call the internal spec function, IteratorClose
when there is an abrupt completion in the loop body (an exception was
thrown, return and break)
The point of this was to allow cleaning up the
On 10 September 2014 16:52, Mark S. Miller erig...@google.com wrote:
On Wed, Sep 10, 2014 at 7:45 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
I see two options here.
1. Add IteratorClose to all places in the spec where we use iterators.
Why was #1 rejected? I just don't remember.
I
On 10 September 2014 17:56, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We agree at our June meeting to add the return method to generators and to
conditionally call return (if it is present) when a for-of loop terminates
before it exhausts its generator. See
On 31 July 2014 00:05, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
I think this subtle discrepancy is both unfortunate and unnecessary
[1]. Moreover, with ES7 do expressions, I would like it to hold that
(...) = {...}≡(...) = do {...}
I channeled you as best
On 17 July 2014 19:29, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
On 16 July 2014 18:38, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
(Note that this topic is on the agenda for this month's TC39 meeting)
Unfortunately, I won't be at the meeting. Do you think we can
On 16 July 2014 18:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
(Note that this topic is on the agenda for this month's TC39 meeting)
Unfortunately, I won't be at the meeting. Do you think we can afford
to defer this until September?
(Also, note that as far as I can tell, the
ES6 will have block scoping. However, it turns out that there are at
least two different forms of blocks in the language:
- normal block statements
- block-like bodies hardwired into other constructs (try/catch bodies,
function bodies)
In the current draft spec, these come with different rules
On 28 June 2014 20:23, Rick Waldron waldron.r...@gmail.com wrote:
On Saturday, June 28, 2014, Brendan Eich bren...@mozilla.org wrote:
Ok, nerdbait -- but I'll take it and champion it at the next TC39 meeting.
Thanks,
Yes, if you hadn't I would've :)
I doubt there will be an opposition, but
On 27 June 2014 21:45, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
On 30 June 2014 19:01, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Jun 30, 2014 at 10:27 AM, Jan Keromnes j...@mozilla.com wrote:
I'd just like to add that joke requests like Math.TAU that have no
place in the language specification itself generate a considerable
amount of overhead for
On 30 June 2014 19:01, C. Scott Ananian ecmascr...@cscott.net wrote:
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features
Some observations:
* I think the 'import * as x' syntax for module imports is not an
improvement, for at least two reasons:
- It raises the expectation that you can actually write 'import *
from' (as already noted in this thread).
- It removes the syntactic marker for binding a module
On 27 June 2014 18:36, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static
On 27 June 2014 17:32, Kevin Smith zenpars...@gmail.com wrote:
So to me the path forward is clear: we keep real modules, axe the default
feature, and take a temporary hit of dissatisfaction from existing users so
that we can expand the JS user base.
Note that the other half of my argument was
On 27 June 2014 21:26, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses
On 18 June 2014 09:40, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
## Benefits
* As with Allen's proposal, we would drop [[Construct]] and the
`construct`
trap.
* @@create can be dropped
On 13 June 2014 18:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We could consider special cases loop bodies that are BlockStatements and
statically reject those that contain declaration that shadow the loop
declarations. However, I think it is probably best to leave that sort of
On 13 June 2014 12:33, Tom Van Cutsem tomvc...@gmail.com wrote:
One important detail:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
I prefer Jason's transformation for the following reason: imagine a
On 11 June 2014 18:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Other than the Array.of and Array.from usages the other uses are all
necessary either functionally (you can't just try to construct by calling
[[Construct]], it requires an explicit guard) or to deal with special
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places you
need it (using eval to introduce new symbols into global scope).
You don't necessarily need sloppy mode for that. In strict mode, you
can still express it as
On 5 June 2014 16:08, John Barton johnjbar...@google.com wrote:
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg rossb...@google.com
wrote:
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places
you
need
C-style for-loops allow declarations as init statements, but only some
of them. Yet, the others (function and class) are actually
syntactically legal in that position as well, because they are simply
parsed as expressions. Consider:
let x = 0
for (let x = 1; ;) x // 1
for (const x = 1; ;)
On 5 June 2014 17:44, John Lenz concavel...@gmail.com wrote:
That is to say, is this valid:
if (x) {
f();
function f() { doSomething() }
}
The same question applies to class declarations. I assume that top level
class declarations hoist. (Where is this in the spec?)
Yes, that is
with making
that change as well, on the grounds that it is more regular.
/Andreas
However, I agree that banning these is much less surprising than allowing
them as expressions rather than declarations.
On Thu, Jun 5, 2014 at 7:58 AM, Andreas Rossberg rossb...@google.com
wrote:
C-style
the
language to make such things illegal.
The point is not so much that it is pointless or nonsensical, but that
it has surprising and arguably inconsistent meaning.
/Andreas
On Jun 5, 2014, at 7:58 AM, Andreas Rossberg rossb...@google.com wrote:
C-style for-loops allow declarations as init
On 4 June 2014 00:12, John Lenz concavel...@gmail.com wrote:
No I intentionally used let. This is not legacy code (I shouldn't have
use the word existing) but new sloppy mode code that would like the code
to be block scoped.
Why would you want to write new sloppy mode code, though? Honest
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict mode. That is,
'use strict'; .x = 0
would throw in ES5, but AFAICS, no longer does in ES6. Was this change
discussed? What is the rationale?
(FWIW, current implementations
On 28 May 2014 13:41, André Bargull andre.barg...@udo.edu wrote:
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict mode. That is,
'use strict'; .x = 0
would throw in ES5, but AFAICS, no longer does in ES6. Was this change
On 28 May 2014 14:08, André Bargull andre.barg...@udo.edu wrote:
On 5/28/2014 2:00 PM, Andreas Rossberg wrote:
On 28 May 2014 13:41, André Bargull andre.barg...@udo.edu wrote:
Apparently, there has been a semantic change between ES5 and ES6
regarding assignment to wrapper objects in strict
On 21 May 2014 14:33, Claude Pache claude.pa...@gmail.com wrote:
I have thought about the right semantics (and the issues) of the existential
operator.
user.getPlan?().value?.score;
The intended semantics of `?` is that, whenever its LHS evaluates to `null`
or `undefined`,
the
On 2 May 2014 14:45, Claude Pache claude.pa...@gmail.com wrote:
The algorithm given in [Bug 1908, comment 2]
(https://bugs.ecmascript.org/show_bug.cgi?id=1908#c2) is problematic, as a
property name blacklisted by an `@@unsopables` anywhere on the prototype
chain will also be blacklisted
On 29 April 2014 20:35, David Herman dher...@mozilla.com wrote:
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
Indeed I expect that in
practice most iterators in an ES6 program will be map, set, and array
iterators, which in practice will not be implemented with generators.
-example?
On Wed, Apr 30, 2014 at 3:48 AM, Andreas Rossberg rossb...@google.com
wrote:
On 29 April 2014 20:35, David Herman dher...@mozilla.com wrote:
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
Indeed I expect that in
practice most iterators in an ES6 program will be map
The way destructuring assignment currently is specified leads to
rather inconsistent evaluation order. Consider:
let o = {}
function f() { print(1); return o }
function g() { print(2); return 5 }
f().x = g()// 1, 2
{a: f().x} = {a: g(}} // 2, 1
That is, destructuring assignments
On 15 April 2014 18:06, Allen Wirfs-Brock allen.wirfsbr...@gmail.com wrote:
AWB: We _could_ add a `return()` method.
... It's a bigger change, but we could make for-of invoke `return()` on exit
or completion
This would be a _significant_ cost. One reason we got rid of the
StopIteration
On 19 April 2014 20:14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I'm in the middle of updating the spec. of [[OwnPropertyKeys]] to returns an
Array rather than an Iterator. While doing this I realized that because
[[OwnPropertyKeys]] is essentially a new MOP level operation we have the
On 22 April 2014 16:52, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Apr 22, 2014, at 12:02 AM, Andreas Rossberg wrote:
On 19 April 2014 20:14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The ordering I propose is:
1) All array index property keys, in ascending array index numeric
## Revisiting: Generator Issues
(Jafar Husain)
[...]
JH: The crucial problem: the iterator claims to be an iterable and it's not.
...If async generators return Iterables, not Iterators.
WH: How
JH: If I accept an iterable and invoke `@@iterator`, I would expect to get a
fresh iterator
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
speaks of typed objects comparing structurally. Typed objects have identity,
On 3 April 2014 09:00, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The
current
discussion
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
You can never compare uvalues from different realms: both uvalues need
to be in the same realm before you can do the comparison. All you
need is that equal uvalues in realm A become equal uvalues in realm B
when passed over.
On 3 April 2014 15:30, Marius Gundersen gunder...@gmail.com wrote:
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg rossb...@google.com
wrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
On 3 April 2014 15:39, C. Scott Ananian ecmascr...@cscott.net wrote:
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg rossb...@google.com wrote:
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
Unfortunately, that only works for primitives because the respective
constructor
On 2 April 2014 16:32, Niko Matsakis n...@alum.mit.edu wrote:
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
On 2 April 2014 19:37, Niko Matsakis n...@alum.mit.edu wrote:
Along those lines, user-defined values (uvalues) probably ought to
have the following characteristics:
- uvalues are (shallowly) immutable
- uvalues have no generative identity, and are compared using by-value ===
- uvalues have a
On 28 March 2014 23:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
For the sake of examples, I honestly find current V8 hack, tested in node.js
inconsistent, kinda pointless, and quite disturbing, with or without strict
code.
I don't know what your notion of current is, but this bug
On 14 March 2014 00:59, Oliver Hunt oli...@apple.com wrote:
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content
that breaks with it disallowed (a particularly prominent one currently is
On 7 March 2014 08:40, Axel Rauschmayer a...@rauschma.de wrote:
// Localization and formatting
l10n`Hello ${name}; you are visitor number ${visitor}:n! You have ${money}:c
in your account!`
A correct German translation of this would have to take the gender of the
visitor into consideration:
On 18 February 2014 10:43, Yehuda Katz wyc...@gmail.com wrote:
On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
Since both Chrome and FIrefox have plans to support Promises, feel
free
On 15 February 2014 21:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote:
C. Scott Ananian wrote:
On Feb 15, 2014 9:13 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Aside: ECMASpeak is neither accurate (we don't
On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote:
On further reflection, #3 does feel like trying to rewrite the past.
For better or worse, non-strict mode allows declarations to persist past
On 14 February 2014 00:32, C. Scott Ananian ecmascr...@cscott.net wrote:
For your consideration, here is an implementation of Monadic Promises,
as a Promise subclass:
Since promises are expressible in JS you can always create a new class
that does what you want. It's also well-understood that
On 8 February 2014 21:43, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Yes, but it also depends upon Promise[Symbol.create] being implemented.
Right. V8 has not yet implemented @@create yet (and it will likely
take some time until it does, since it's a rather intrusive feature).
/Andreas
On 5 February 2014 11:17, Mark S. Miller erig...@google.com wrote:
At the end of Sept mtg, my memory of the state on entry to the meeting
agrees completely with Domenic's. On exit, my memory is
a) We had agreed to promote both the .then level and the .chain level to
ES6. (This is probably the
On 5 February 2014 12:10, Alex Russell slightly...@google.com wrote:
On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
I'd rather we keep separate and conflict-prone APIs in separate objects,
though. I'd rather we acknowledge that Promises are a library de-facto
I really regret that I couldn't be there on the last day of the
meeting, and share the frustration I hear in this thread. I honestly
have a hard time viewing this as a consensus, if for nothing else
than that I do not consent. :)
For the record, let me repeat what I wrote in a private
On 5 February 2014 18:35, Domenic Denicola dome...@domenicdenicola.com wrote:
The evolution of DOM and ES promises, and the related fragile consensuses,
has been an involved process.
Going back to the source documents, consider what the May AP2 proto-consensus
really is: Abashed Monadic
101 - 200 of 778 matches
Mail list logo
