Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 4:33 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > >Expression ::= ... | lambda Formals? Statement > Statement or SubStatement? If Statement, what meaning do you propose for { const f = (lambda () const x = 3;); x } Does the const export its binding i

Re: Hoisting behaviour of 'const' and 'let'

On Sat, Oct 11, 2008 at 8:35 PM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > The reason for making 'const' hoist to the top of the enclosing block, > AFAIR, was consistency with function declarations. However, there are > good reasons why 'const'/'let' and function declarations should be > tre

Re: Hoisting behaviour of 'const' and 'let'

David-Sarah Hopwood wrote: > Mark S. Miller wrote: > > On Sat, Oct 11, 2008 at 4:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > >>> If we want to avoid the read-barrier, we should not hoist either const > >>> or let. If we are to consider not hoisting const, WE NEED TO DECIDE > >>> THIS NOW, befo

Re: Hoisting behaviour of 'const' and 'let'

David-Sarah Hopwood wrote: [...] > What is proposed to be hoisted in the case of 'const' and 'let' is just > the point at which the variable's *scope* begins. But, unlike the case > of function definitions, this in general extends the scope to a point > where the variable has not been initialized.

Hoisting behaviour of 'const' and 'let'

Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 4:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: >>> If we want to avoid the read-barrier, we should not hoist either const >>> or let. If we are to consider not hoisting const, WE NEED TO DECIDE >>> THIS NOW, before ES3.1 mandates a hoisting const. >

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 3:16 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > The reason people like let blocks and expressions as opposed to let > declarations, from what I can tell, is precisely the lack of hoisting to top > of block done for let declarations, and the greater clarity of head-scope

Re: return when desugaring to closures

On Oct 11, 2008, at 4:02 PM, Mark S. Miller wrote: > Let's say, further, that > a lambda's parameter list is syntactically optional. This makes for ambiguities if we do not require a braced expression, as Dave pointed out. Requiring braces always goes against the expression/statement unificat

Re: return when desugaring to closures

On Oct 11, 2008, at 7:13 PM, Mark S. Miller wrote: > Cool! So why are we still discussing proposed let expressions and let > blocks as distinct constructs? I'm open to just having a single form, which is an expression whose body is a statement. In fact, way back (about 2 to 2.5 years ago)

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 4:05 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > Read the proposal again: the statement form of lambdas *does* return the > value of its last expression; this is what ES3 calls the "completion value." At : > Expressi

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 4:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: >> If we want to avoid the read-barrier, we should not hoist either const >> or let. If we are to consider not hoisting const, WE NEED TO DECIDE >> THIS NOW, before ES3.1 mandates a hoisting const. > > A few messages back you

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 4:05 PM, Dave Herman <[EMAIL PROTECTED]> wrote: > Read the proposal again: the statement form of lambdas *does* return the > value of its last expression; this is what ES3 calls the "completion value." Cool! So why are we still discussing proposed let expressions and let bl

Re: return when desugaring to closures

Read the proposal again: the statement form of lambdas *does* return the value of its last expression; this is what ES3 calls the "completion value." Dave On Oct 11, 2008, at 7:02 PM, Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 3:26 PM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> Of c

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 3:26 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > Of course, let expressions would need lambda-coding no matter what > names were shadowed. The experience gained in JS1.7+ shows more let > block usage than let expression, but expression temporaries (lacking > macros and ign

Re: return when desugaring to closures

On Oct 11, 2008, at 3:45 PM, Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 3:30 PM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> What's more, as discussed here and in TC39, repeated let >> declarations for >> the same binding name within the same block should be allowed. >> Anything else >

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 6:38 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > On Sat, Oct 11, 2008 at 3:25 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >> [...] I'd just like a >> non-hoisting 'let.' Based on what you wrote about hoisting earlier in >> this thread, I'm surprised you don't want one,

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 3:30 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > What's more, as discussed here and in TC39, repeated let declarations for > the same binding name within the same block should be allowed. Anything else > is user- and refactoring-hostile. So the non-initial let declarations

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 3:25 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote: > [...] I'd just like a > non-hoisting 'let.' Based on what you wrote about hoisting earlier in > this thread, I'm surprised you don't want one, too. History aside, my preference would be what E does: A variable is in scope

Re: Strengthening Function.prototype.toString

On Sat, 11 Oct 2008 04:52:20 +0200, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: >> > Yeah. Opera Mobile returned "[ECMAScript code]" or "[ecmascript >> > code]". >> > Anybody know if those issues have been fixed in more modern versions? >> >> No, not consistently across "modern versions". It's not

Re: return when desugaring to closures

On Oct 11, 2008, at 2:55 PM, Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 2:42 PM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> We've discussed making use-before-set a strict error, but we've >> avoided it. The initialiser is not mandatory, and we do not wish to >> impose costly analysis on s

Re: return when desugaring to closures

On Oct 11, 2008, at 3:16 PM, Brendan Eich wrote: > Of course everything could be lambda-coded, but that's not harmonious > or usable. Just let as new var is agreed upon, and let blocks and > expressions could be let coded if there is no name shadowing (else > they'd need lambda-coding). Of course

Re: return when desugaring to closures

Hi Dave, first, my compliments on your lambda proposal. This should significantly simplify the core language after expanding sugars -- especially if you succeed at redefining function as desugaring to lambdas. That would be awesome! On Sat, Oct 11, 2008 at 5:34 AM, David Herman <[EMAIL PROTECTED]

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 5:24 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > On Sat, Oct 11, 2008 at 1:36 PM, Peter Michaux <[EMAIL PROTECTED]> wrote: >> Simplifying >> >> (lambda (x = 3, y = x) (x+y))() >> >> to just >> >> let (x = 3, y = x) (x+y) >> >> makes it much more clear when reading code w

Re: return when desugaring to closures

On Oct 11, 2008, at 2:24 PM, Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 1:36 PM, Peter Michaux > <[EMAIL PROTECTED]> wrote: >> Simplifying >> >> (lambda (x = 3, y = x) (x+y))() >> >> to just >> >> let (x = 3, y = x) (x+y) >> >> makes it much more clear when reading code what the intention o

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 2:42 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > We've discussed making use-before-set a strict error, but we've > avoided it. The initialiser is not mandatory, and we do not wish to > impose costly analysis on small implementations. Since "const" use-before-set is an unc

Re: return when desugaring to closures

On Oct 11, 2008, at 2:43 PM, Brendan Eich wrote: > On Oct 11, 2008, at 12:52 PM, Peter Michaux wrote: > >> and if it is partly in then which of > >> the several JavaScript 1.7 uses are in and if there will be "let", >> "let*", "letrec" semantics. > > It's something else. See my reply about hoistin

Re: return when desugaring to closures

On Oct 11, 2008, at 12:52 PM, Peter Michaux wrote: On Sat, Oct 11, 2008 at 11:59 AM, Brendan Eich <[EMAIL PROTECTED]> wrote: On Oct 11, 2008, at 9:05 AM, Peter Michaux wrote: How to define a variable that is local to the enclosing lambda? Isn't the ability to do that essential? Use let (

Re: return when desugaring to closures

On Oct 11, 2008, at 12:55 PM, David Herman wrote: >> How to define a variable that is local to the enclosing lambda? Isn't >> the ability to do that essential? > > No. With all due respect to Brendan, `var' hoisting to the top of a > function body is one of the more problematic aspects of ES's

Re: return when desugaring to closures

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 scoping of a lambda name works t

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 1:36 PM, Peter Michaux <[EMAIL PROTECTED]> wrote: > Simplifying > > (lambda (x = 3, y = x) (x+y))() > > to just > > let (x = 3, y = x) (x+y) > > makes it much more clear when reading code what the intention of the > programmer was. If the need for this case were common, tha

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 1:21 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > The let declaration is in. Like const and function declarations, it > has block-level letrec lexical scoping. I continue to oppose let > expressions and let statements, as they don't provide enough > additional power to j

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 12:52 PM, Peter Michaux <[EMAIL PROTECTED]> wrote: >> Use let (the var replacement declaration form). > > Sounds good to me but it is a little confusing to keep track if "let" > is either in or out of ES-Harmony and if it is partly in then which of > the several JavaScript 1

Re: return when desugaring to closures

> Sounds good to me but it is a little confusing to keep track if "let" > is either in or out of ES-Harmony and if it is partly in then which > of > the several JavaScript 1.7 uses are in and if there will be "let", > "let*", "letrec" semantics. I've got no crystal ball, but I'd say it'd be unlike

Re: return when desugaring to closures

> 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. Dave ___ Es-discuss mailing list Es-discu

Re: return when desugaring to closures

> How to define a variable that is local to the enclosing lambda? Isn't > the ability to do that essential? No. With all due respect to Brendan, `var' hoisting to the top of a function body is one of the more problematic aspects of ES's semantics. If you want a local variable, use `let' -- it'll

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 11:59 AM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Oct 11, 2008, at 9:05 AM, Peter Michaux wrote: > >> How to define a variable that is local to the enclosing lambda? Isn't >> the ability to do that essential? > > Use let (the var replacement declaration form). Sounds g

Re: return when desugaring to closures

Peter Michaux wrote: > On Sat, Oct 11, 2008 at 7:12 AM, David-Sarah Hopwood > <[EMAIL PROTECTED]> wrote: >> Yuh-Ruey Chen wrote: > >>> I read through the strawman:lambdas proposal and saw that it did not >>> mention anything about |var|, e.g. >>> >>> (function() { >>> lambda { >>>var x

Re: return when desugaring to closures

On Oct 11, 2008, at 9:05 AM, Peter Michaux wrote: > How to define a variable that is local to the enclosing lambda? Isn't > the ability to do that essential? Use let (the var replacement declaration form). /be ___ Es-discuss mailing list Es-discuss@moz

Re: Revenge of the double-curly [Was: return when desugaring to closures]

On Oct 11, 2008, at 7:25 AM, David-Sarah Hopwood wrote: > It is correct to say, though, that: > > function foo() { >... >{ var bar = baz; } >... > } > > is equivalent to > > function foo() { >let bar = undefined; >... >{ bar = baz; } >... > } > > That is, 'var' need

Re: return when desugaring to closures

Peter Michaux wrote: > On Sat, Oct 11, 2008 at 10:02 AM, Mark S. Miller <[EMAIL PROTECTED]> wrote: >> On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux <[EMAIL PROTECTED]> wrote: >>> As it stands, I always write the following in ES3 >>> >>> var f = function() {}; >>> >>> and now that arguments.callee

Re: return when desugaring to closures

David Herman wrote: > > Does the |var| within the lambda define a var in the function body, > > and does that var declaration hoist to the top of the function body? > > Good catch, thank you. Since `lambda' is designed to have no implicit > semantics, it can't introduce a new `var' frame. IOW, the

Re: Strengthening Function.prototype.toString

Inline. Yuh-Ruey Chen wrote: > > So as far as I can tell, what we need to discourage usage of > func.toString() is: > > 1) An API for function currying/partial evaluation (specializing/binding > certain arguments). > 2) A read-only property on functions that contains the list of parameter > name

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 10:02 AM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux <[EMAIL PROTECTED]> wrote: >> As it stands, I always write the following in ES3 >> >> var f = function() {}; >> >> and now that arguments.callee is on the chopping block, I'v

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 9:11 AM, Peter Michaux <[EMAIL PROTECTED]> wrote: > As it stands, I always write the following in ES3 > > var f = function() {}; > > and now that arguments.callee is on the chopping block, I've started > writing recursion as the painful contortion below > > var f = (function

Re: return when desugaring to closures

On Fri, Oct 10, 2008 at 7:28 PM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: > I wonder if we really need named lambdas in the first place. I consider > the whole named function/let/var thing to be messy enough already. Is it > really that too difficult to do this: > > let f = lambda() { ... } > > An

Re: return when desugaring to closures

On Sat, Oct 11, 2008 at 7:12 AM, David-Sarah Hopwood <[EMAIL PROTECTED]> wrote: > Yuh-Ruey Chen wrote: >> I read through the strawman:lambdas proposal and saw that it did not >> mention anything about |var|, e.g. >> >> (function() { >> lambda { >>var x = 10; >> }(); >> return x

Re: Revenge of the double-curly [Was: return when desugaring to closures]

Brendan Eich wrote: > On Oct 10, 2008, at 11:58 AM, P T Withington wrote: > >> ? If so, perhaps you can see how I might imagine that: >> >> function foo () {{ >> var bar = ...; >> }} >> >> might be sugar for: >> >> function foo () { >> let bar = ...; >> } > > Nope, not compatible

Re: return when desugaring to closures

Yuh-Ruey Chen wrote: > David Herman wrote: >>> My question was whether the semantics of break and continue would >>> support the following: >> Yes, this is another good case to consider. Thanks for pointing it out; >> I'll add this to the strawman:lambdas proposal. Essentially this is >> another as

Re: return when desugaring to closures

> The only sensible thing would be to run all of them; local "break" > even does that in ES3. Yes. > Of course that raises the question of what happens if a "break" whose > matching activation frame is no longer live would generate an error > but a finally clause would have caught and diverted it

Re: return when desugaring to closures

> if (h == 0) > h = function() {break}; Did you mean if (x == 0)? That's been confusing me in trying to read your example. Dave ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: return when desugaring to closures

> Does the |var| within the lambda define a var in the function body, > and does that var declaration hoist to the top of the function body? Good catch, thank you. Since `lambda' is designed to have no implicit semantics, it can't introduce a new `var' frame. IOW, the `var' would still be hoiste