Rick Waldron wrote:
# Global Scope Revisit
YK: Still not in agreement with discussion yesterday, but not blocking
the
BE: Recap the problem that revealed the issue.
LH: Can we talk about let/var at the top level?
Current proposal… let would shadow var
ARB: Why?
BE: Global contour in
Rick Waldron wrote:
# Thin Arrow?
(Presented by Brendan Eich, Mozilla)
We have the fat-arrow, supported by Kevin Smith's research, it's a
win. Some voices in the community don't want the unexpected behaviour
of the soft-bound lexical `this`
bound 'this' would do -- hard-bound if you insist.
On Thu, Sep 27, 2012 at 11:54 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
# Thin Arrow?
(Presented by Brendan Eich, Mozilla)
We have the fat-arrow, supported by Kevin Smith's research, it's a win.
Some voices in the community don't want the unexpected behaviour of the
On Thu, Sep 27, 2012 at 11:44 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
# Global Scope Revisit
YK: Still not in agreement with discussion yesterday, but not blocking the
BE: Recap the problem that revealed the issue.
LH: Can we talk about let/var at the top level?
Rick Waldron wrote:
Notably: Significant dissent on throwing exceptions for [iteration
protocol termination] control flow.
Counter-argument based on Python design and experience is that by far
the most uses of iterators never have to try/catch and simply use for-of
(for-in in Python)
On Sep 28, 2012, at 7:54 AM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
# Thin Arrow?
(Presented by Brendan Eich, Mozilla)
We have the fat-arrow, supported by Kevin Smith's research, it's a win. Some
voices in the community don't want the unexpected behaviour of the
Thanks Rick for the notes (and everyone who contributed, I see several
colors)
Le 28/09/2012 03:00, Rick Waldron a écrit :
# Proxy
(Presented by Tom Van Cutsem, Free University of Brussels)
## Revokable Proxies
(...)
Question as to whether we really need two kinds of proxies.
BE: yes,
On 28 September 2012 03:30, Bill Frantz fra...@pwpconsult.com wrote:
(BTW -
I know of no completely specified languages, or other computer system
components for that matter, but the closer the specification comes to being
complete, the better).
Off-topic, but I can't resist pointing out here
My bad, I sent the previous email to es-discuss-owner instead of to es-discuss.
Forwarding Brendan’s answer to everyone.
Begin forwarded message:
From: Brendan Eich bren...@mozilla.com
Subject: Re: Object.prototype.__proto__
Date: September 28, 2012 16:25:06 GMT+02:00
To: Axel Rauschmayer
On Thu, Sep 27, 2012 at 10:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
Another:
The notes from last week's meeting said WRT function parameter bindings:
Conclusion/Resolution
- `var` bindings and are in scope within the function
- cannot use `let` to shadow a parameter
In any
On Sep 27, 2012, at 10:54 PM, Brendan Eich bren...@mozilla.org wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're
able to determine a function should fail on first execution you can
determine that it could fail during parsing and semantic
It is my understanding of B.3.1 that Object.prototype.__proto__’s only use
is as a flag to switch off __proto__ for all objects (I’m assuming in
settings similar to Caja). Wouldn’t it be better to introduce a real boolean
flag, along with a unique name object?
No.
First, __proto__ is
Ugh, sorry about that. I had a momentary brain melt and forgot to unformat
before sending
-Rick
On Friday, September 28, 2012 at 4:20 AM, David Bruant wrote:
Thanks Rick for the notes (and everyone who contributed, I see several colors)
Le 28/09/2012 03:00, Rick Waldron a écrit :
#
Nothing new in this section in this draft and what is there will eventually get
a significant rewrite...
On Sep 27, 2012, at 9:32 PM, Axel Rauschmayer wrote:
B.3.1, “The __proto__ pseudo property” will eventually be moved out of the
annex, right?
If I may: I have two questions about this
On Sep 27, 2012, at 1:40 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
I'm all for statically disallowing many of these stupid cases and I
think it is fine to do the checks at first call rather than load-time (a
off-line static linter could be more aggressive in reporting such
On Sep 28, 2012, at 7:58 AM, John Lenz wrote:
On Thu, Sep 27, 2012 at 10:12 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Another:
The notes from last week's meeting said WRT function parameter bindings:
Conclusion/Resolution
- `var` bindings and are in scope within the
On Sep 28, 2012, at 8:00 AM, Axel Rauschmayer wrote:
It is my understanding of B.3.1 that Object.prototype.__proto__’s only use
is as a flag to switch off __proto__ for all objects (I’m assuming in
settings similar to Caja). Wouldn’t it be better to introduce a real
boolean flag, along
Alex Russell wrote:
On Sep 28, 2012, at 7:54 AM, Brendan Eichbren...@mozilla.org wrote:
Rick Waldron wrote:
# Thin Arrow?
(Presented by Brendan Eich, Mozilla)
We have the fat-arrow, supported by Kevin Smith's research, it's a win. Some
voices in the community don't want the unexpected
Allen Wirfs-Brock wrote:
I generally use static to mean: solely based upon analysis of the program text
without any dependencies upon runtime state. That's my criteria for classifying something as
part of the language's static semantics (which includes early errors).
Ok so far.
All ES
Oliver Hunt wrote:
On Sep 27, 2012, at 10:54 PM, Brendan Eichbren...@mozilla.org wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during
Hi David,
replies in-line below:
2012/9/28 David Bruant bruan...@gmail.com
Thanks Rick for the notes (and everyone who contributed, I see several
colors)
Le 28/09/2012 03:00, Rick Waldron a écrit :
# Proxy
(Presented by Tom Van Cutsem, Free University of Brussels)
## Revokable
On Sep 27, 2012, at 10:54 PM, Brendan Eich wrote:
Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're
able to determine a function should fail on first execution you can
determine that it could fail during parsing and semantic analysis.
Ok, to
David Bruant wrote:
I think it's possible to implement both without any overhead.
TVC suggested below that a revoked proxy is equivalent to a proxy with
all traps unconditionally throwing; well, a proxy, when revoke could
drop its target and change its handler on revokation.
In the words of
Allen Wirfs-Brock wrote:
I see a potential benefit to implementor in the deferred early error concept
and there are implementation alternatives that would be lost without it. I see a minor
negative impact to developers. They would need to take an extra pre-deployment action in
order to be
Le 28/09/2012 17:31, Rick Waldron a écrit :
Ugh, sorry about that. I had a momentary brain melt and forgot to
unformat before sending
Ahah, don't worry about it :-)
David
___
es-discuss mailing list
es-discuss@mozilla.org
Right. I think it's pretty.
--
Dr. Axel Rauschmayer
rauschma.de
[Sent from a mobile device, please forgive brevity and typos]
On Sep 28, 2012, at 18:55, David Bruant bruan...@gmail.com wrote:
Le 28/09/2012 17:31, Rick Waldron a écrit :
Ugh, sorry about that. I had a momentary brain melt and
On Sep 28, 2012, at 9:54 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I see a potential benefit to implementor in the deferred early error
concept and there are implementation alternatives that would be lost without
it. I see a minor negative impact to developers. They would need to
On Sep 28, 2012, at 9:16 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I generally use static to mean: solely based upon analysis of the program
text without any dependencies upon runtime state. That's my criteria for
classifying something as part of the language's static semantics
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit. Adding startup overhead
should be something TC39 is actively working against.
The early errors/first run errors can be caught by other tools as well
(linters, in browser developer
Le 28/09/2012 18:28, Tom Van Cutsem a écrit :
Discussion about whether revokable proxies introduce new ways for
interceptable operations to behave.
WH: Not sure about this as a feature, w/r to future hostility…
- eg. if === would trap to the handler how does this work with
But, it's all moot, as this is destined to be completely rewritten.
Got it. Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
David Bruant wrote:
This point started with an what if typeof/=== is trappable?. If it's
sure that it never becomes trappable, everything's good.
I'm not sure everything's good -- MM at the meeting (Mark Miller ;-)
said lots would change. We don't need to future-proof by inventing that
Allen Wirfs-Brock wrote:
It isn't clear to me that there is much difference between an invocation-fused explosive
function-level and a similarly fused script file or module. The triggering of each of
these normally occurs at some point after some application code has executed to even if
we
Le 28/09/2012 19:56, Brendan Eich a écrit :
David Bruant wrote:
This point started with an what if typeof/=== is trappable?. If
it's sure that it never becomes trappable, everything's good.
I meant If it's sure that *they* (typeof/===) never become trappable,
everything's good (in the sense
John Lenz wrote:
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit.
Ahem, gmail, cough. :-/
Adding startup overhead should be something TC39 is actively working
against.
I take a different view, since as you say machines
Allen Wirfs-Brock wrote:
On Sep 28, 2012, at 9:16 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I generally use static to mean: solely based upon analysis of the program text
without any dependencies upon runtime state. That's my criteria for classifying something as
part of the
On Sep 28, 2012, at 11:23 AM, Brendan Eich wrote:
We do! Where's the list of candidate early error cases? Cc'ing Luke.
Within recent ES6 drafts, all early errors are identified within subsections
labeled: Static Semantics: Early Errors
The easiest way to see all of them is just to do a
On Fri, Sep 28, 2012 at 11:14 AM, Brendan Eich bren...@mozilla.org wrote:
John Lenz wrote:
The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit.
Ahem, gmail, cough. :-/
Spreadsheets, document editor, photo editor, games,
John Lenz wrote:
The best thing I see for the future is if the Browser vendors didn't
reparse JavaScript when loading from cache, this would help the best
case scenarios, but doesn't help the worse case where it harder to
find wins.
Yes, why hasn't this happened? We had a Mozilla intern
In method environment records, you have HomeObject and MethodName, whereas
function objects have the properties [[Home]] and [[MethodName]]. This is
really just a minor nitpick, but it might make sense to rename [[Home]] to
[[HomeObject]].
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home:
feel free to file a bug
On Sep 28, 2012, at 1:07 PM, Axel Rauschmayer wrote:
In method environment records, you have HomeObject and MethodName, whereas
function objects have the properties [[Home]] and [[MethodName]]. This is
really just a minor nitpick, but it might make sense to rename
On Sep 28, 2012, at 20:58, Brendan Eich bren...@mozilla.org wrote:
John Lenz wrote:
The best thing I see for the future is if the Browser vendors didn't reparse
JavaScript when loading from cache, this would help the best case scenarios,
but doesn't help the worse case where it harder to
* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
As I understand it, this goes back to lazy parsing
http://ariya.ofilabs.com/2012/07/lazy-parsing-in-javascript-engines.html
which, in turn, seems to
Import is currently used by Module. This way of using import looks like a
loader feature.
2012/9/26 Russell Leggett russell.legg...@gmail.com
On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 csf...@gmail.com wrote:
Thanks, Claus and Alex,
I've looked at the Loader but it seems to be async?
I know
So what I've got is we need static meta data for Module exports. For this
reason export keyword is needed.
I was considering if these meta data could be given by the user of Module
(instead of author of Module).
If module file could only be used in ES6 (on need lexical convertion), I
thinking
45 matches
Mail list logo
