On Mon, Oct 13, 2008 at 10:48 PM, Mark S. Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
I'm talking about a rewrite from 'for' to
'lambda' that satisfies the following properties:
1) for (var i = 0; i len; i++) ... continues to mean
David-Sarah Hopwood wrote:
[proposed expansions for 'for (let' and 'for (const']
Note that if the condExpr or updateExpr captures i, some implementation
details of how these expansions work will be exposed. Don't do that.
--
David-Sarah Hopwood
___
On Oct 13, 2008, at 6:39 PM, Brendan Eich wrote:
Users may be modeling closures as capturing bindings, not scope chains
of mutable objects, one per for (let...) statement or explicitly
braced block. If so, could we make let declaration capture this way?
Again, I'm proceeding from real users'
David-Sarah Hopwood wrote:
Neil Mix wrote:
The for/closures bug is definitely a newbie trap, but its pain is
not its discovery, but the difficulty of working around it. To me
this could be a winning argument against re-binding on each loop,
since re-binding precludes the (admittedly
On Oct 14, 2008, at 7:38 AM, Neil Mix wrote:
On Oct 13, 2008, at 6:39 PM, Brendan Eich wrote:
Users may be modeling closures as capturing bindings, not scope
chains
of mutable objects, one per for (let...) statement or explicitly
braced block. If so, could we make let declaration capture
On Oct 14, 2008, at 7:17 AM, David-Sarah Hopwood wrote:
This is subject to the criticism that the loop variable(s) are
implicitly mutable in the update expression (only), when they were
declared it to be const.
My point was simpler: sometimes it is handy to write for (const x...)
and have
On Oct 14, 2008, at 7:17 AM, David-Sarah Hopwood wrote:
Requirement 3 is met because var hoists to the enclosing function.
Assuming that var hoisting is done before this expansion, yes.
Absolutely -- var hoisting across lambdas to preserve TCP is prior
magic, assumed by the (revised) lambda
What about for-in loops?
I'm proceeding from user expectations being confounded. Something
needs help here, possibly not for (;;) loops -- but almost certainly
for-in loops containing closures capturing the loop variable.
Whatever is done should be consistent between for and for-in. My
On 2008-10-11, at 08:34EDT, David Herman wrote:
Thank you for pointing out, though, that try/catch isn't so easily
defined on top of return-to-label, since it still needs special
handling for finally. The options are either to define a lower-level
primitive underlying try/finally (akin
Neil Mix wrote:
Brendan Eich wrote:
So we can have our cake and eat it too with a tail-recursive
desugaring that forwards the previous iteration's binding value to
the next iteration's binding. [...]
Yeah, I got lost in the thread and missed the subtlety of that follow-
up. I'm
Brendan Eich wrote:
What did you mean by had better fail to compile? Other than the
type annotation, there is nothing about
function f() {
x = 15;
...
var t = some_runtime_expression;
...
var x:t = ...
}
that ought to fail to compile.
The assignment to x in that temporal dead
David-Sarah Hopwood wrote:
David-Sarah Hopwood wrote:
Waldemar Horwat wrote:
I am talking about let bindings. Lars brought up at that meeting. I did
not find the use cases particularly convincing, but the dead zone is
compelling. There are four ways to do this:
A1. Lexical dead zone.
David-Sarah Hopwood wrote:
Igor Bukanov wrote:
2008/10/13 David-Sarah Hopwood [EMAIL PROTECTED]:
This is slightly more complex than I'd hoped, but I think the guarantee
that it is never possible to see uninitialized values of 'const' or 'let'
variables is worth it.
What about the functions
Jon Zeppieri wrote:
On Mon, Oct 13, 2008 at 10:48 PM, Mark S. Miller [EMAIL PROTECTED] wrote:
You're right. However, the desugaring is more complex than I expected.
Thanks for asking me to write it down.
for (keyword varName = initExpr; testExpr; updateExpr) { body }
desugars to (hygienic
On Oct 14, 2008, at 12:39 PM, Waldemar Horwat wrote:
PS. What does lambda(x = y){...}() mean? Is it different from
lambda(x){...}(y)?
No.
What does lambda(x = y){...}(z) do when z is undefined?
Passes undefined bound to x. Undefined is not the same as missing.
These are my answers
On Oct 14, 2008, at 1:36 PM, Brendan Eich wrote:
On Oct 14, 2008, at 12:39 PM, Waldemar Horwat wrote:
What does lambda(x = y){...}(z) do when z is undefined?
Passes undefined bound to x. Undefined is not the same as missing.
Lest anyone think otherwise, missing means actual argument count
Neil Mix wrote:
The for/closures bug is definitely a newbie trap, but its pain is
not its discovery, but the difficulty of working around it. To me
this could be a winning argument against re-binding on each loop,
since re-binding precludes the (admittedly dubious) use-case of
17 matches
Mail list logo
