On 28 December 2012 20:53, David Herman dher...@mozilla.com wrote:
On Dec 28, 2012, at 11:47 AM, Andreas Rossberg rossb...@google.com wrote:
That seems clean, useful, consistent, and fairly easy to understand.
Introducing extra rules for 'let'? Not so much.
But TDZ does introduce extra
On 28 December 2012 07:10, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms
above, but that is irrelevant, because that difference can only be observed
for
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow
an example like the above.
Can these plenty be enumerated? Apart from const, which ones have TDZs?
/be
On 28 December 2012 11:22, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow an
example like the above.
Can these plenty be enumerated?
On Dec 28, 2012, at 2:11 AM, Andreas Rossberg rossb...@google.com wrote:
That doesn't prove that it was a *bug*. That's a question about the
programmer's intention. In fact, I don't think you can. For example, I
mentioned let-binding at the bottom:
{
console.log(x);
On Dec 28, 2012, at 2:29 AM, Andreas Rossberg rossb...@google.com wrote:
Can these plenty be enumerated? Apart from const, which ones have TDZs?
All declarations whose initialization cannot be hoisted. My understanding is
that that would be 'const', 'class' and 'private', although we have
On Dec 28, 2012, at 11:47 AM, Andreas Rossberg rossb...@google.com wrote:
We can identify two classes of lexical declarations:
1. Those where initialization can be performed at the start of the scope
(which is what I meant by hoisted above), and the bound variable can safely
be accessed
Andreas Rossberg wrote:
1. Those where initialization can be performed at the start of the
scope (which is what I meant by hoisted above),
The h-word will die hard. I think most people use it to mean this, i.e.,
function hoisting. With var context it means binding but not
initialization
Andreas Rossberg wrote:
For the second (let, const, class, private -- although TBH, I forgot
the reason why 'class' is in this group),
To future-proof against class static syntax that can be effectful.
/be
___
es-discuss mailing list
David Herman wrote:
For the first group (function, module), there is no problem. For the second
(let, const, class, private -- although TBH, I forgot the reason why 'class' is in
this group), we have temporal dead zone, where accessing a variable before its
initialization is an error.
The
On 27 December 2012 01:50, David Herman dher...@mozilla.com wrote:
On Dec 11, 2012, at 2:45 AM, Andreas Rossberg rossb...@google.com wrote:
The question, then, boils down to what the observation should be: a
runtime error (aka temporal dead zone) or 'undefined'. Given that
choice, the
On Dec 27, 2012, at 1:23 AM, Andreas Rossberg rossb...@google.com wrote:
Let's start with TDZ-RBA. This semantics is *totally untenable* because it
goes against existing practice. Today, you can create a variable that starts
out undefined and use that on purpose:
I think nobody ever
On Dec 27, 2012, at 1:51 AM, Andreas Rossberg rossb...@google.com wrote:
I think hoisting can mean different things, which kind of makes this debate a
bit confused.
Yep. Sometimes people mean the scope extends to a region before the syntactic
position where the declaration appears, sometimes
On 27 December 2012 21:08, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:23 AM, Andreas Rossberg rossb...@google.com wrote:
var x;
if (...) { x = ... }
if (x === undefined) { ... }
If you want to use let instead, the === if-condition will throw. You
would
On 27 December 2012 21:23, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:51 AM, Andreas Rossberg rossb...@google.com wrote:
I think hoisting can mean different things, which kind of makes this
debate a bit confused.
Yep. Sometimes people mean the scope extends to a region
On 27 December 2012 23:38, Andreas Rossberg rossb...@google.com wrote:
I don't feel qualified to talk for Scheme, but all Ocaml I've ever
seen (SML uses more verbose 'let' syntax anyway) formatted the above as
let sq = x * x in
print (sq: ^ toString sq ^ \n);
let y = sq / 2 in
David Herman wrote:
ES1 in 1995
JS if you please! No ES till 1996 November at earliest, really till
June 1997.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms above,
but that is irrelevant, because that difference can only be observed for
erroneous programs (i.e. where the first version throws, because 'x'
On Dec 11, 2012, at 2:45 AM, Andreas Rossberg rossb...@google.com wrote:
Late to the party, sorry. First, let's be clear there are a couple possible
semantics that could be called temporal dead zone. At this point I'm not sure
what various people had in mind; I suspect different people may have
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of David Herman
Sent: Wednesday, December 26, 2012 19:50
I imagine your reply is: don't do that transformation; place your `let`
declarations as late as possible before they are going to be used. I
I guess to sum up what I think Domenic was saying: people hoist var
declarations so that their code acts the way the engine is going to execute
it in order to prevent a mismatch between expectations and result. If there
wasn't a reason to do that (AKA TDZ-UBI) then it wouldn't be done, because
Rick Waldron wrote:
On Wednesday, December 26, 2012, Brandon Benvie wrote:
I guess to sum up what I think Domenic was saying: people hoist
var declarations so that their code acts the way the engine is
going to execute it in order to prevent a mismatch between
expectations and
On Dec 26, 2012, at 7:40 PM, Brendan Eich bren...@mozilla.com wrote:
Many also believe that hoisting is an excellent feature, not a weirdness.
For functions, I can defend hoisting, although if I had had more time, I
might have done a let ... in ... or BCPL'ish equivalent form that groups
On Dec 26, 2012, at 8:36 PM, David Herman dher...@mozilla.com wrote:
- JS is dynamically scoped, so having an implicit dummy value isn't a problem
for the type system.
Holy misnomers, batman. I meant dynamically typed. May Bob Harper have mercy on
my soul. [1]
Dave
[1] He won't. He'll
On 10 December 2012 21:59, Claus Reinke claus.rei...@talk21.com wrote:
Second, it doesn't eliminate the need for temporal dead zones at all.
You could well be right, and I might have been misinterpreting what
temporal dead zone (tdz) means.
For a letrec, I expect
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
On 6 December 2012 22:26, Claus Reinke claus.rei...@talk21.com wrote:
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
On 5 December 2012 19:19, Claus Reinke claus.rei...@talk21.com wrote:
their operational generativity perhaps being a mismatch with their
seemingly static meaning in certain syntactic forms,
This appears to be ungrounded. See below.
Personally, I also consider that a non-issue, but it was
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
On 6 December 2012 17:25, Claus Reinke claus.rei...@talk21.com wrote:
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
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
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
On Tue, Dec 4, 2012 at 8:28 AM, Claus Reinke claus.rei...@talk21.comwrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far?
Nov 28 TC39 Meeting Notes:
Recall the main objection was not the generativity of @names mixed with the obj.@foo pun
(after-dot). It was the usability tax of having to declare
private @foo;
before defining/assiging
obj.@foo = foo;
(in a constructor, typically).
Good clarification, thanks. Yes, the more important
On 4 December 2012 14:28, Claus Reinke claus.rei...@talk21.com wrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far? You don't
want to have to search for these useful clarifications when this topic
comes up again (be it in
Andreas Rossberg wrote:
Indeed. (Although I don't think we have implicit let-scopes in JS.)
Only in comprehensions and generator expressions, which have an explicit
outer syntax.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form will
be something like:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
From: Brandon
I think the important thing to recognize is that @names was an *extremely* late
proposal, and it's just way too late for ES6, but that doesn't at all mean it's
out for good. The deadline for new features was in the spring of *2011* after
all! Now, the fact that we considered it at all was due
Until ES7. If we try to solve all problems in ES6, it might not ship
earlier than ES7 anyway.
On Mon, Dec 3, 2012 at 4:38 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that
On Dec 3, 2012, at 4:38 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form
will be something like:
let iterable = { *[iterator]() { yield
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
I'm sorry, but I reject this kind of argument. That code is simply more
concise than:
let iterable = { [iterator]: function*() { yield 5 } };
Given that the concise notation means that ': function' is
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
the ES7-is-around-the-corner wager for two reasons.
The first reason is that I believe it's likely going to be a lot harder to
get syntax changes into
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
the ES7-is-around-the-corner wager for two reasons.
The first reason
On Dec 3, 2012, at 6:27 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 3, 2012 at 6:14 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't buy
Axel Rauschmayer wrote:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
I'm sorry, but I reject this kind of argument. That code is simply
more concise than:
let iterable = { [iterator]: function*() { yield 5 } };
Given that the concise notation means that
Sorry, didn't realize that had another meaning. I mean anything that causes
a syntax error when attempting to run it.
On Mon, Dec 3, 2012 at 9:28 PM, David Herman dher...@mozilla.com wrote:
On Dec 3, 2012, at 6:27 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 3, 2012 at 6:14 PM,
Ah. Gotcha. Yes, that's a good point. But even though such changes are
costly and less needed by ES7, I expect ES7 will nevertheless have
some further syntax enhancements that don't work on ES6. The main
example is the minimality of min-max classes, These really really need
to be made more usable
On Dec 3, 2012, at 6:14 PM, Brandon Benvie bran...@brandonbenvie.com wrote:
I understand that there's limitations on what can be packed into this release
and in particular this proposal pushes the limits.
Look, that's all it comes down to. All the various @names proposals have
problems. No
Brandon Benvie wrote:
I understand that there's limitations on what can be packed into this
release and in particular this proposal pushes the limits. But I don't
buy the ES7-is-around-the-corner wager for two reasons.
Neither ES6 (+1 years) nor ES7 (+4) is around the corner.
You are
On Dec 3, 2012, at 6:35 PM, Brendan Eich bren...@mozilla.org wrote:
Recall the main objection was not the generativity of @names mixed with the
obj.@foo pun (after-dot). It was the usability tax of having to declare
private @foo;
before defining/assiging
obj.@foo = foo;
(in a
David Herman wrote:
(That said, the generativity does worry me. It's a smell.)
Just to be super-sure we grok one another, it's not the generativity by
itself (since nested function declarations are the same, as I mentioned
in the meeting). It is the generativity combined with the obj.@foo
-0800 (PST)
Subject: Re: On dropping @names
David Herman wrote:
(That said, the generativity does worry me. It's a smell.)
Just to be super-sure we grok one another, it's not the generativity by
itself (since nested function declarations are the same, as I mentioned
in the meeting
52 matches
Mail list logo
