Re: return when desugaring to closures

On Oct 21, 2008, at 5:56 PM, David-Sarah Hopwood wrote: >> If we got in wrong in ES3.1, we couldn't fix it later. > > That's true, but I still hope to convince you and the group that we > can > get it right for ES3.1. With zero implementations due to lack of a spec that hangs together in full

Re: return when desugaring to closures

Mark S. Miller wrote: > On Tue, Oct 21, 2008 at 3:42 PM, Waldemar Horwat <[EMAIL PROTECTED]> wrote: >> What does ES3.1 do if you have both const x and var x at the top level? > > It just so happens that we discussed top level const in this morning's > ES3.1 phone meeting. It never occurred to us t

Re: return when desugaring to closures

On Tue, Oct 21, 2008 at 3:42 PM, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > What does ES3.1 do if you have both const x and var x at the top level? It just so happens that we discussed top level const in this morning's ES3.1 phone meeting. It never occurred to us to ban top level const. We did d

Re: return when desugaring to closures

Brendan Eich wrote: > Followup to discuss some open issues from the thread, evident in the > message cited below: > > 1. Unifying var scope and let scope at top level of a function could be > done, with tolerable restrictions: given let x at top level in a > function body, existence of formal p

Re: return when desugaring to closures

Followup to discuss some open issues from the thread, evident in the message cited below: 1. Unifying var scope and let scope at top level of a function could be done, with tolerable restrictions: given let x at top level in a function body, existence of formal parameter x, and redeclaration

Re: return when desugaring to closures

Eric Suen wrote: > I think top-down parser has no issue to parse following code: > > function() { > }(); > > but this is not a valid statement because: > > ExpressionStatement ::= [lookahead ! {{, function}] Expression ; There is a good reason for that. It's because of semicolon insertion. Yo

Re: return when desugaring to closures

On Oct 17, 2008, at 7:36 PM, Eric Suen wrote: > Are you sure about that, because you using hand written top-down > parser, > Is it confirmed by a top-down parser generator like ANTLR? I haven't used ANTLR or any other LL(*) parser generator, no. I found http://code.google.com/p/antlr-javascrip

Re: return when desugaring to closures

BTW function() return b ? c : d should be function() b ? c : d Regards, Eric Suen ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: return when desugaring to closures

>> The parser is required to backtrack until it either finds an >> expansion of the grammar that doesn't generate a syntax error or >> until it discovers that they all do. You can choose to make >> additional syntax errors as per chapter 16, but that does not >> relieve you of the backtracking req

Re: return when desugaring to closures

On Oct 17, 2008, at 11:17 AM, Waldemar Horwat wrote: > Maciej Stachowiak wrote: >> As to the else issue, I don't think that ambiguity can be avoided, >> but bison lets you solve that with %nonassoc, which is a sound >> disambiguation mechanism. > > It can. I have a machine-validated ES3 (and

Re: return when desugaring to closures

On Oct 16, 2008, at 3:40 PM, Brendan Eich wrote: > For now I favor the lambda expression form as well as the lambda > block form. Good thing I added "For now". Since I'm convinced by Waldemar's argument against ambiguity, I have to drop support for the lambda expression form. It could be re

Re: return when desugaring to closures

On Oct 17, 2008, at 11:30 AM, Brendan Eich wrote: > In that case the -NoIn sub-grammar should apply, extended to > LetExpressionNoIn. So > > for (let (a = b) c in d); Sorry, of course that should have been for (var a = let (b = c) b in d); /be ___ Es-

Re: return when desugaring to closures

On Oct 17, 2008, at 11:05 AM, Waldemar Horwat wrote: > Brendan Eich wrote: >> Is this a perfectly valid for-in statement? >> >> for (a = b in c); >> >> Not according to ES3's grammar. An assignment expression is not >> valid on >> the left of the for-in's "in": >> >> /IterationStatement /*:* >>

Re: return when desugaring to closures

Maciej Stachowiak wrote: > I think it might be better to write the official ES3.1 grammar in this > way, even though it is a little annoying and repetitive, so it can more > readily be verified that the language grammar has no ambiguities by > running through a parser-generator like yacc or biso

Re: return when desugaring to closures

Maciej Stachowiak wrote: > As to the else issue, I don't think that ambiguity can be avoided, but > bison lets you solve that with %nonassoc, which is a sound > disambiguation mechanism. It can. I have a machine-validated ES3 (and ES4 from earlier proposals) grammar that contains no ambiguitie

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote: > >> The parser is required to backtrack until it either finds an expansion >> of the grammar that doesn't generate a syntax error or until it >> discovers that they all do. You can choose to make additional syntax >> er

Re: return when desugaring to closures

On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote: The parser is required to backtrack until it either finds an expansion of the grammar that doesn't generate a syntax error or until it discovers that they all do. You can choose to make additional syntax errors as per chapter 16, but that

Re: return when desugaring to closures

On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote: On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-

Re: return when desugaring to closures

On Thu, Oct 16, 2008 at 5:49 PM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > [lots of good stuff snipped] I agree. > The degenerate syntax "let {...}" allowed by this grammar at first-sight > doesn't seem very useful, until you realize that it has a similar effect > (apart from not preventin

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: > >> I don't think you can come up with a consistent "shift" or "greedy" >> notion. > > Funny, yacc has had one for decades, used to resolve dangling-else. > > >> The one you may be thinking of will happily accept code s

Re: return when desugaring to closures

On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-else. Which ES1-3 also use: 12.5 The if Statement

Re: return when desugaring to closures

Mark S. Miller wrote: > On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman <[EMAIL PROTECTED]> wrote: >> In the grammar for proposed ES4, LetExpression was under >> PrimaryExpression. That's where I'm suggesting LambdaExpression might >> fit. IOW: >> >> PrimaryExpression ::= ... >>|

Re: return when desugaring to closures

On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote: > SpiderMonkey historically used SyntaxError, not ReferenceError, and > throw at compile-time. This pre-dates ES1. Another example not > involving let expressions: > > js> a + b = c > typein:1: SyntaxError: invalid assignment left-hand side: > t

Re: return when desugaring to closures

On Oct 15, 2008, at 1:28 PM, Mark S. Miller wrote: > On Wed, Oct 15, 2008 at 12:31 PM, Dave Herman <[EMAIL PROTECTED]> > wrote: >> Do you prefer (lambda Formals Block | lambda Formals Expression)? >> [Personally I'm fine with that.] Or do you oppose any lambda >> expressions >> at all? Or did

Re: return when desugaring to closures

On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote: I don't think you can come up with a consistent "shift" or "greedy" notion. Funny, yacc has had one for decades, used to resolve dangling-else. The one you may be thinking of will happily accept code such as let (a = 5) x + y.foo = 2; y

Re: return when desugaring to closures

On Wed, Oct 15, 2008 at 4:49 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > In the grammar for proposed ES4, LetExpression was under > PrimaryExpression. That's where I'm suggesting LambdaExpression might > fit. IOW: > > PrimaryExpression ::= ... >| LetExpression >

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> That's not a valid grammar. > > It is unambiguous. How do you define "valid"? > >>> You can't have an AssignmentExpression terminating a >>> PrimaryExpression. It leads to trouble such as:

Re: return when desugaring to closures

On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote: > Brendan Eich wrote: >> That's not a valid grammar. It is unambiguous. How do you define "valid"? >> You can't have an AssignmentExpression terminating a >> PrimaryExpression. It leads to trouble such as: > > let a = b + c > > being inter

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote: > >> There is no such thing as a "let expression". > > Let expressions > in > JS1.7 (Firefox 2+), based on the ES4 proposal >

Re: return when desugaring to closures

On Oct 15, 2008, at 6:13 PM, Brendan Eich wrote: On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote: There is no such thing as a "let expression". Let expressions in JS1.7 (Firefox 2+), based on the ES4 proposal. ES3-ish grammar: LetExpression : let ( VariableDeclarationList ) [lo

Re: return when desugaring to closures

On Oct 15, 2008, at 2:36 PM, Waldemar Horwat wrote: There is no such thing as a "let expression". Let expressions in JS1.7 (Firefox 2+), based on the ES4 proposal. ES3- ish grammar: LetExpression : let ( VariableDeclarationList ) [lookahead ∉ {{}] AssignmentExpression produced fro

Re: return when desugaring to closures

>>> Please specify what you are proposing. The one proposal I've seen is: >>> >>> Expression ::= ... | lambda Formals Statement > Dave Herman wrote: >> Yes, that's what I meant, or at least what I thought Yuh-Ruey meant. >> >>> This is not particularly useful because then even assign a lambda to

Re: return when desugaring to closures

I know you are well aware of the LetExpression form that was in proposed ES4 and has been implemented in Firefox since JS 1.7 -- why are you sounding like you've never heard of it? In the grammar for proposed ES4, LetExpression was under PrimaryExpression. That's where I'm suggesting LambdaExpr

Re: return when desugaring to closures

Dave Herman wrote: >> Please specify what you are proposing. The one proposal I've seen is: >> >> Expression ::= ... | lambda Formals Statement > > Yes, that's what I meant, or at least what I thought Yuh-Ruey meant. > >> This is not particularly useful because then even assign a lambda to a >>

Re: return when desugaring to closures

On Wed, Oct 15, 2008 at 12:31 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > Do you prefer (lambda Formals Block | lambda Formals Expression)? > [Personally I'm fine with that.] Or do you oppose any lambda expressions > at all? Or did you have something else in mind? My preference is "lambda" F

Re: return when desugaring to closures

> Please specify what you are proposing. The one proposal I've seen is: > > Expression ::= ... | lambda Formals Statement Yes, that's what I meant, or at least what I thought Yuh-Ruey meant. > This is not particularly useful because then even assign a lambda to a > variable would be a syntax e

Re: For Loop Desugaring (was: return when desugaring to closures)

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

Re: For Loop Desugaring (was: return when desugaring to closures)

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

Re: return when desugaring to closures

On Oct 14, 2008, at 11:19 AM, Waldemar Horwat wrote: > Brendan Eich wrote: >>> 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 zone before t's initializer

Re: For Loop Desugaring (was: return when desugaring to closures)

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 ( = ; ; ) { } >> >> desugars to (hygienic renaming aside): >> >> breakT

Re: return when desugaring to closures

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

Re: return when desugaring to closures

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

Re: return when desugaring to closures

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 (ak

Re: return when desugaring to closures

> 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.

Re: For Loop Desugaring (was: return when desugaring to closures)

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) lam

Re: For Loop Desugaring (was: return when desugaring to closures)

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

Re: return when desugaring to closures

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

Re: return when desugaring to closures

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 (adm

Re: return when desugaring to closures

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 >

Re: For Loop Desugaring (was: return when desugaring to closures)

On Tue, Oct 14, 2008 at 2:38 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 10:48 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote: >> >> I believe this meets all your requirements. > > I believe it does. Very cool. It won't handle the fully general > for(;;). E.g., > > for (l

Re: return when desugaring to closures

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 use

Re: For Loop Desugaring (was: return when desugaring to closures)

Brendan Eich wrote: > On Oct 13, 2008, at 7:48 PM, Mark S. Miller wrote: > >> On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >>> 1) for (var i = 0; i < len; i++) ... continues to mean what it >>> means in ES3. >>> 2) for (let i = 0; i < len; i++) ... has the proper scop

Re: For Loop Desugaring (was: return when desugaring to closures)

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++) ... continu

Re: For Loop Desugaring (was: return when desugaring to closures)

On Oct 13, 2008, at 7:48 PM, Mark S. Miller wrote: > On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >> 1) for (var i = 0; i < len; i++) ... continues to mean what it >> means in ES3. >> 2) for (let i = 0; i < len; i++) ... has the proper scope for 'i' >> (which you reit

Re: return when desugaring to closures

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. References textually

Re: return when desugaring to closures

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. References textually prior to a definition in the > s

For Loop Desugaring (was: return when desugaring to closures)

On Mon, Oct 13, 2008 at 5:00 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >>> Mark said that there was a desugaring for 'for' to 'lambda,' without >>> special cases, where this all works out, but I haven't been able to >>> figure out what rewrite he had in mind. > > That's not the point. I'm talkin

Re: return when desugaring to closures

On Oct 13, 2008, at 6:08 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >>> Because presumably the "let x:t" became "var x:t" and var can't have >>> types? >> >> Why can't var have a type annotation? > > Because a function can have many var declarations for the same > variable and because you

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 13, 2008, at 5:29 PM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote: >>> Brendan Eich wrote: > After some experiments, we decided for ES4 to make let and var the > same at top level in a function or

Re: return when desugaring to closures

On Oct 13, 2008, at 5:29 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote: >> >>> Brendan Eich wrote: After some experiments, we decided for ES4 to make let and var the same at top level in a function or global code. ... >>> You

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> After some experiments, we decided for ES4 to make let and var the >>> same at top level in a function or global code. >>> >>> This helped avoid implementation pain: very long scripts on the web,

Re: return when desugaring to closures

Jon Zeppieri wrote: >> Why is the assignment operator relevant? The question is the binding >> scope of i in >> >> for (let i = 0; i < N; i++) ... > > > How is scope the issue? As far as I know, we don't disagree about scope. > > The assignment I'm referring to, in this example, is the 'i++'

Re: return when desugaring to closures

On Oct 13, 2008, at 4:54 PM, 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. References textually p

Re: return when desugaring to closures

David Herman wrote: >> Also, I wonder why lambda in it's block-less form is restricted to >> expressions. > > I'm with you... but I'd want to check with the experts on the ES grammar to > see whether this introduces any nasty ambiguities. Please specify what you are proposing. The one proposal

Re: return when desugaring to closures

On Oct 13, 2008, at 5:00 PM, Jon Zeppieri wrote: > On Mon, Oct 13, 2008 at 7:39 PM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote: >> >>> Yes, and binding a fresh induction variable on every iteration makes >>> sense for a 'for-each' loop (as in the

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 7:39 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote: > >> Yes, and binding a fresh induction variable on every iteration makes >> sense for a 'for-each' loop (as in the bug report you cited), where >> the user is not in charge o

Re: return when desugaring to closures

Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux <[EMAIL PROTECTED]> wrote: >> I think it would be ok to have only unnamed lambdas. (It would be ok >> to have named lambdas too.) > > I think we should not introduce named lambdas because then we'd need > to decide whether the

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> If using an uninitialized let binding is an error, then hoisting is >>> pointless except to make the statements between start of block and the >>> let declaration a dead zone for the binding name

Re: return when desugaring to closures

On Oct 13, 2008, at 4:09 PM, Brendan Eich wrote: > On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> If using an uninitialized let binding is an error, then hoisting is >>> pointless except to make the statements between start of block and >>> the >>> let declaration

Re: return when desugaring to closures

David-Sarah Hopwood wrote: > Mark S. Miller wrote: >> [...] I recommend the per-iteration view. If we can >> agree quickly on per-iteration, then >> >> for (const x = ...) {...x...} >> >> should be allowed in ES3.1 (whether or not const hoists to block >> start). After ES3.1 >> >> for (cons

Re: return when desugaring to closures

On Oct 13, 2008, at 4:17 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> True enough -- but even without normalization, multiple equivalent >> (at >> runtime, depending on flow) annotations could be allowed. Should >> they be? > > No. Just because the type matched the last five times you

Re: return when desugaring to closures

On Oct 13, 2008, at 4:14 PM, Jon Zeppieri wrote: > Yes, and binding a fresh induction variable on every iteration makes > sense for a 'for-each' loop (as in the bug report you cited), where > the user is not in charge of updating the induction variable by means > of explicit assignment. In a plai

Re: return when desugaring to closures

Brendan Eich wrote: > On Oct 13, 2008, at 3:56 PM, Waldemar Horwat wrote: > >> Brendan Eich wrote: >>> The agreement from the May TC39 meeting was that the declarations >>> implicit (:*) and explicit annotations must normalize to the same >>> type, or there's an error. >> >> That was back when the

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 6:34 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > > On the contrary, what's magical is when one stores i in elements of an > array, or calls setTimeout (example in > https://bugzilla.mozilla.org/show_bug.cgi?id=449811) > , and the results are all the last value of the loop

Re: return when desugaring to closures

On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> If using an uninitialized let binding is an error, then hoisting is >> pointless except to make the statements between start of block and >> the >> let declaration a dead zone for the binding name. This fits the >> anci

Re: return when desugaring to closures

Brendan Eich wrote: > If using an uninitialized let binding is an error, then hoisting is > pointless except to make the statements between start of block and the > let declaration a dead zone for the binding name. This fits the > ancient, weak but not entirely worthless post-hoc rationale fo

Re: return when desugaring to closures

On Oct 13, 2008, at 3:56 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> The agreement from the May TC39 meeting was that the declarations >> implicit (:*) and explicit annotations must normalize to the same >> type, or there's an error. > > That was back when the language had lots of requirem

Re: return when desugaring to closures

On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote: > Brendan Eich wrote: >> After some experiments, we decided for ES4 to make let and var the >> same at top level in a function or global code. >> >> This helped avoid implementation pain: very long scripts on the web, >> consisting of many statem

Re: return when desugaring to closures

Brendan Eich wrote: > The agreement from the May TC39 meeting was that the declarations > implicit (:*) and explicit annotations must normalize to the same > type, or there's an error. That was back when the language had lots of requirements for compile-time expressions, including on all type

Re: return when desugaring to closures

Brendan Eich wrote: > After some experiments, we decided for ES4 to make let and var the > same at top level in a function or global code. > > This helped avoid implementation pain: very long scripts on the web, > consisting of many statements in a row, motivate statement-wise > parsing and

Re: return when desugaring to closures

On Oct 13, 2008, at 1:16 PM, David-Sarah Hopwood wrote: > In the "i++", which iteration's 'i' is the LeftHandSideExpression > referring to? Or does this expand to something like: > > let ($i = 0) { >for (; > let (i = $i) {i < 10}; > let (i = $i) {{i++;} $i = i;}} { > let

Re: return when desugaring to closures

On Oct 13, 2008, at 8:43 AM, Mark S. Miller wrote: > On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> "for (var ...)" implicitly introduces a block whether or not it >> is a substatement. This is a wart of C++/C99/Java syntax that >> we have to live with, since

Re: return when desugaring to closures

On Oct 12, 2008, at 9:34 PM, Mark S. Miller wrote: > On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> In ES3.1, this will mean that they normally require braces whenever a >> body can introduce variables. There are two classes of exceptions, >> shown by these ex

Re: return when desugaring to closures

On Oct 12, 2008, at 1:39 PM, David-Sarah Hopwood wrote: >> |lambda() return 10| >> would not require such a block scope. Why not have the block scope >> only >> created if there are curly brackets? That would follow the >> precedent set >> by the rest of the language with regards to block scop

Re: return when desugaring to closures

On Oct 12, 2008, at 12:48 PM, Yuh-Ruey Chen wrote: > Now that I think about it, would it truly be necessary for lambda to > create an implicit block scope in the first place? |lambda() return > 10| > would not require such a block scope. Implementation, or optimization, detail. > Why not have

Re: return when desugaring to closures

David Herman wrote: >> if (h == 0) >> h = function() {break}; > > Did you mean if (x == 0)? That's been confusing me in trying to read your > example. No. I meant the code as it was originally written. Waldemar ___ Es-discuss mailin

Re: return when desugaring to closures

David-Sarah Hopwood wrote: > Mark S. Miller wrote: >> But what about "let". Do we all agree that in >> >> for (let x = ...) {...x...} >> ... x ... >> >> the x after the for loop does not refer to the x defined by the for >> loop? > > Yes, if this form is allowed. The other options are eith

Re: return when desugaring to closures

Mark S. Miller wrote: > On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> "for (var ...)" implicitly introduces a block whether or not it >> is a substatement. This is a wart of C++/C99/Java syntax that >> we have to live with, since too much code relies on it. >

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 12:47 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 9:13 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >> But then it becomes extremely awkward for the 'let' or 'const' case to >> use a fresh variable on every iteration. It ties the semantics of >> 'for

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 9:13 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: > I like your intention here -- I brought up the iteration variable / > closure issue earlier in the thread -- but this seems rather messy. > > In the 'var' case, x must be the same throughout, no? yes. > function foo() {

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 11:43 AM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> "for (var ...)" implicitly introduces a block whether or not it >> is a substatement. This is a wart of C++/C99/Java syntax that >> we h

Re: return when desugaring to closures

On Mon, Oct 13, 2008 at 8:05 AM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > "for (var ...)" implicitly introduces a block whether or not it > is a substatement. This is a wart of C++/C99/Java syntax that > we have to live with, since too much code relies on it. Yes, but how do we live with i

Re: return when desugaring to closures

Mark S. Miller wrote: > On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> In ES3.1, this will mean that they normally require braces whenever a >> body can introduce variables. There are two classes of exceptions, >> shown by these examples: >> >> a) while (...)

Re: return when desugaring to closures

On Sun, Oct 12, 2008 at 7:55 PM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > In ES3.1, this will mean that they normally require braces whenever a > body can introduce variables. There are two classes of exceptions, > shown by these examples: > > a) while (...) foo: var x = ...; > b) while (

Re: return when desugaring to closures

YR Chen wrote: > On Sun, Oct 12, 2008 at 7:34 PM, David-Sarah Hopwood < > [EMAIL PROTECTED]> wrote: > >> So why are we arguing about whether lambdas should be allowed without >> braces, when the direction being taken for the rest of the language >> is to make the braces mandatory around all forms

Re: return when desugaring to closures

2008/10/12 YR Chen <[EMAIL PROTECTED]>: > On Sun, Oct 12, 2008 at 7:34 PM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> >> So why are we arguing about whether lambdas should be allowed without >> braces, when the direction being taken for the rest of the language >> is to make the braces man

Re: return when desugaring to closures

On Sun, Oct 12, 2008 at 5:45 PM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > Since LabelledStatement is included in SubStatement, the following is > allowed in the current ES3.1 draft: > > while (...) foo: var x = ...; This will be corrected in the next version. But the agreed fix is not to

Re: return when desugaring to closures

On Sun, Oct 12, 2008 at 7:34 PM, David-Sarah Hopwood < [EMAIL PROTECTED]> wrote: > So why are we arguing about whether lambdas should be allowed without > braces, when the direction being taken for the rest of the language > is to make the braces mandatory around all forms that can potentially > d

Re: return when desugaring to closures

Mark S. Miller wrote: > On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: >> David-Sarah Hopwood wrote: >>> { while (...) let x = ...; } >> I was under the impression that such statements should be disallowed, >> following the example of JS1.8. In JS1.8 (Fx3), the followin

Re: return when desugaring to closures

Mark S. Miller wrote: > On Sun, Oct 12, 2008 at 2:19 PM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: >> David-Sarah Hopwood wrote: >>> { while (...) let x = ...; } >> I was under the impression that such statements should be disallowed, >> following the example of JS1.8. In JS1.8 (Fx3), the followin

  1   2   3   >