Returning just arrays will be inconsistent with the same name methods that
sit on prototypes of Array, Map, etc.
Yes, Object.keys(...) poisons the iterators idea, but I think these better
to be iterators.
Or, if Object.values and Object.entries will start returning simple arrays
(which of cours
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 Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com wrote:
I would also like to see this standardized. Comments inline.
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 like to
It sounds like you want a standardized debugger and profiler API, rather
than a language feature. Every engine is different enough internally that I
don't think it makes sense to have a standardized debugger API.
That said, the Mozilla Debugger API is quite impressive. It might make
sense to look
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 Sep 29, 2014, at 7:55 AM, John Lenz concavel...@gmail.com wrote:
On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo fpi...@apple.com
mailto:fpi...@apple.com wrote:
I would also like to see this standardized. Comments inline.
On Sep 27, 2014, at 10:15 PM, John Lenz
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 Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote:
I really have no idea what the behavior should be in the faces of optimized
tail calls (which is must broader than simply self recursive methods that
can be rewritten as a loop). I've seen various suggestions (a capped
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 Mon, Sep 29, 2014 at 12:06 PM, Filip Pizlo fpi...@apple.com wrote:
[...]
I haven't actually seen anything about tail recursion optimizations being
implemented, have any of the VM actually tried or committed to implementing
tail call optimizations?
We (JSC) haven’t. And we don’t plan to,
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 welcome0.
To add to confusion, ES6 drafts say Tail Position Calls
On Sep 29, 2014, at 10:25 AM, 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
On Sep 29, 2014, at 9:23 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Sep 29, 2014 at 12:06 PM, Filip Pizlo fpi...@apple.com wrote:
[...]
I haven't actually seen anything about tail recursion optimizations being
implemented, have any of the VM actually tried or committed to
On Sep 29, 2014, at 9:23 AM, Mark S. Miller wrote:
Although we would both like to see function.caller gone as well, we are also
both much more skeptical that this is possible. Let's assume that it is not.
The conclusion that follows is only that sloppy calls to sloppy functions
can't be
Agreed. TCO or PTC specified only for strict mode functions, not for all
non-sloppy functions.
Would be nice to extend this at least to bound functions resulting from
binding a strict function, but too late to consider for ES6. In any case,
all such TCO extensions can compatibly happen later.
On Sep 29, 2014, at 11:00 AM, Mark S. Miller wrote:
Agreed. TCO or PTC specified only for strict mode functions, not for all
non-sloppy functions.
Would be nice to extend this at least to bound functions resulting from
binding a strict function, but too late to consider for ES6. In any
On Sat, 27 Sep 2014, Anne van Kesteren wrote:
Well, I for one find it confusing that while HTML had a fairly worked
out event loop concept, ECMAScript added another and now I somehow
mentally need to integrate them. It would be way clearer if ECMAScript
just queued tasks/jobs/microtasks
Just wanted to add that CoffeeShop [https://github.com/carlsmith/coffeeshop]
already uses stack traces the way JSFiddle and CodePen may do if they were
standardised. This only works on V8 as it's the only engine that respects
sourceURL 'directives' when listing eval'ed code in stack traces.
Sorry, this paragraph is a bit confusing...
It's currently impossible to build a JavaScript shell in *any* browser. FF
provides line and column numbers for compilation errors, but omits the
actual name, so they may as well just not bother ~ it's impossible to build
a traceback on Gecko
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they want
to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
___
Yes, I believe that we should consider some non-strict non-sloppy
functions, such as .bind()ings of strict functions, to also normatively
have some TCO/PTC requirements. However, it is too late to consider such
for ES6 and we can always extend such TCO/PTC requirements to more cases
later.
On
On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote:
On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote:
I really have no idea what the behavior should be in the faces of optimized
tail calls (which is must broader than simply self recursive methods that
can be rewritten as
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that if they
want to.
The question is whether it should be normative. PTC is about observable
asymptotic space performance (I keep saying :-P).
/be
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So we (at least I) mean normative only in the following sense:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that
loads and runs this script:
throw 0;
let x;
This leaves the binding 'x' uninitialized. There's no way to get rid
of a lexical binding or to initialize it later. The binding is just
permanently hosed; any attempt to
Practically speaking, I agree.
On Mon, Sep 29, 2014 at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller erig...@google.com
wrote:
The issue is the asymptotic space consumption almost-contract. The
reason I
say almost is that
Another way to make this (somewhat) testable is to require specific error.stack
behavior for TCO. For example, a call in tail position may require that the
caller does not show up in the stack trace.
-Filip
On Sep 29, 2014, at 1:16 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls, and as
Steve Fink mentioned, these also arise when considering inlining and
other optimizations. We shouldn't prevent implementations from trying
to experiment with
On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their implementation language.
Function.prototype.apply,
On Sep 29, 2014, at 1:13 PM, Mark S. Miller wrote:
The issue is the asymptotic space consumption almost-contract. The reason I
say almost is that conformance of an implementation is not testable.
Currently, the spec says nothing about when an implementation might run out
of storage.
So
On Sep 29, 2014, at 12:19 PM, Steve Fink sph...@gmail.com wrote:
On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote:
On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com wrote:
I really have no idea what the behavior should be in the faces of optimized
tail calls (which is
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls,
But we should spec one of them, particularly if we want to move towards
On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo fpi...@apple.com wrote:
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
I think this would be a mistake -- as I mentioned, there are a number
of possible strategies for stack traces w/ proper tail calls,
But we
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I can't imagine what you would want be to try to say about non-EMCAScript
functions. Their internal call semantics is determined by the semantics of
their
On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
I certainly wouldn't object to the ES spec's event loop algorithms being
turned inside out (search for RunCode on the esdiscuss thread above for
an e-mail where I propose this) but that would be purely an editorial
change, it
On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that
loads and runs this script:
throw 0;
let x;
This leaves the binding 'x' uninitialized. There's no way to get rid
of a lexical
TDZ
On Sep 29, 2014, at 2:14 PM, Rick Waldron wrote:
On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that
loads and runs this script:
throw 0;
let x;
This leaves the
On Mon, 29 Sep 2014, Anne van Kesteren wrote:
On Mon, Sep 29, 2014 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
I certainly wouldn't object to the ES spec's event loop algorithms
being turned inside out (search for RunCode on the esdiscuss thread
above for an e-mail where I propose this)
On Sep 29, 2014, at 2:05 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Mon, Sep 29, 2014 at 4:57 PM, Filip Pizlo fpi...@apple.com
mailto:fpi...@apple.com wrote:
On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
I think this would be a mistake --
The issues with sourceUrl and syntax errors is fixed in the latest Chrome
dev channel and should be making its way to us in the near future. :-)
On Mon, Sep 29, 2014 at 11:49 AM, Carl Smith carl.in...@gmail.com wrote:
Just wanted to add that CoffeeShop [
On Mon, Sep 29, 2014 at 12:19 PM, Steve Fink sph...@gmail.com wrote:
On 09/29/2014 09:14 AM, Sam Tobin-Hochstadt wrote:
On Mon, Sep 29, 2014 at 10:55 AM, John Lenz concavel...@gmail.com
wrote:
I really have no idea what the behavior should be in the faces of
optimized
tail calls (which
What does TC39 expect with regard to PTC and the
standard-because-everyone-has-one stack property? Has any of the VMs
actually tried to implement PTC for JS?
On Mon, Sep 29, 2014 at 12:02 PM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
No particular reason an
On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
Function.prototype.apply, Function.prototype.call, and Reflect.apply
currently call PrepareForTailCall. Is this a bug?
No, I don't believe so. Built-ins
On 29 September 2014 23:04, John Lenz concavel...@gmail.com wrote:
The issues with sourceUrl and syntax errors is fixed in the latest
Chrome dev channel and should be making its way to us in the near future.
:-)
Awesome. I can add JavaScript support to the shell :)
I still think the
On Sep 29, 2014, at 3:37 PM, Jason Orendorff wrote:
On Mon, Sep 29, 2014 at 4:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
Function.prototype.apply, Function.prototype.call, and Reflect.apply
currently call PrepareForTailCall. Is
Allen Wirfs-Brock wrote:
On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
No particular reason an implementation can't optimize through that
if they want to.
The question is whether it should be normative. PTC is about
observable asymptotic space performance (I
Carl Smith wrote:
I still think the omission of some method for naming eval'ed code in
the ES6 spec is unacceptable. It's not a nice-to-have that can be
bundled with nicer stack objects, which are relatively unimportant
[easily fixed with a regex].
See
On 30 September 2014 00:33, Brendan Eich bren...@mozilla.org wrote:
Carl Smith wrote:
I still think the omission of some method for naming eval'ed code in the
ES6 spec is unacceptable. It's not a nice-to-have that can be bundled with
nicer stack objects, which are relatively unimportant
Carl Smith wrote:
If the source URL hack, or some cleaner wrapper for it, was
standardised, it'd make all the difference.
Why don't we just make the source URL hack a de-facto standard? That's
how evolution happens, in the best case. Cc'ing @fitzgen.
/be
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this program
ran out of space, ever:
var i = 0;
while (1) { i++; };
How would you know whether it does? You can't tell whether your program
is terminated because it runs out
It is a defacto standard.
On Sep 29, 2014 6:36 PM, Brendan Eich bren...@mozilla.org wrote:
Carl Smith wrote:
If the source URL hack, or some cleaner wrapper for it, was standardised,
it'd make all the difference.
Why don't we just make the source URL hack a de-facto standard? That's how
Put it in a worker or node.js. The point Sam was making was based on Ecma-262,
no browser watchdog required.
/be
On Sep 29, 2014, at 6:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/29/14, 4:16 PM, Sam Tobin-Hochstadt wrote:
We'd consider it a spec violation (at least, I would), if this
53 matches
Mail list logo
