Re: return when desugaring to closures
On Oct 9, 2008, at 8:57 PM, Peter Michaux wrote:
This keyword/scoping problem must already have appeared for functions
as function declarations have var scoping and obtaining let
scoping requires using something like let a = function(){}. This is
pretty ugly for functions to have let scoping
An agreement from TC39 this past sprint was that function definitions
directly nested in blocks, not specified by ES3, defined block-local
(let) bindings.
There was general aversion to 'let function f() ...', an earlier ES4
idea already on the ropes. Separating binding forms from function
definition and other options (such as const) avoids too many binding
forms ('let const', 'let function', etc.). But too many binding forms
is just too many, and the committee strongly favored using grammatical
placement to avoid adding more syntactic complexity.
but the good news is
the door has been left open for real lambdas to snatch up the
available var a(){} and let a(){} syntaxes.
There's no reason to add var a() {} given function a() {} as a direct
child of a program or function body. It seems to me let a(){} is
Dave's define. So we're back to function vs. define/lambda.
The idea of a desugaring let statement and let expression require
lambda, the reformed function (whether define wins or not). But let
declarations as the new var do not desugar to lambdas. They hoist,
even if forward references (use before set) are errors.
We haven't found a reformed var; I don't think there is one. This does
not mean let declarations are somehow not worth adding. They're a big
improvement on var declarations in our experience with let in JS1.7
and up.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revenge of the double-curly [Was: return when desugaring to closures]
On 2008-10-10, at 02:29EDT, Brendan Eich wrote:
An agreement from TC39 this past sprint was that function definitions
directly nested in blocks, not specified by ES3, defined block-local
(let) bindings.
2008/10/10 P T Withington [EMAIL PROTECTED]:
Holy smokes. Does that mean we are all going to be writing
function ... () {{
...
}}
to get 'normal' scoping of function body declarations??? Will `var`
mean `let` in those double-curly bodies? Might as well let `let` not
be a keyword...
Haven't we been through this before? ES3 doesn't allow this, but all
browsers do allow it. And all browsers have slightly or entirely
different behaviour. The behaviour of Opera and IE on one hand and
Mozilla and Safari on the other hand is entirely incompatible.
The Harmony decision is incompatible with all browsers, because the
function wouldn't be usable before the block (breaks IE and Opera
behaviour) and would fall out of scope when the block exits (breaks
Mozilla and Safari behaviour).
For example, this works in Mozilla:
if(true){
function fn(){return 'then-path';}
}else{
function fn(){return 'else-path';}
}
fn(); // = 'then-path'
This would be broken by the Harmony design. On the other hand, the
other browsers will result in 'else-path' in the current situation.
(Is this a change in Safari? Unless I'm misremembering the results
last time bundled Safari with Mozilla on this one.)
--
David liorean Andersson
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Caja] GC of name objects in Harmony
Brendan Eich wrote: On Oct 9, 2008, at 6:04 PM, David-Sarah Hopwood wrote: Mike Samuel wrote: Mark, Do you know if the ES3.1 spec specifies GC behavior around Name objects that No Name objects in ES3.1. Yes, please read the post as being about Harmony. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
Peter Michaux wrote:
This keyword/scoping problem must already have appeared for functions
as function declarations have var scoping and obtaining let
scoping requires using something like let a = function(){}. This is
pretty ugly for functions to have let scoping but the good news is
the door has been left open for real lambdas to snatch up the
available var a(){} and let a(){} syntaxes.
... and const a(){} or let const a(){}, which are what you would
want in preference to var or let in the majority of cases for
function definitions.
(Is it just me, or is let const as proposed in
http://wiki.ecmascript.org/doku.php?id=proposals:block_expressions
a bit too verbose? E uses def for constant declarations, and IMHO
it does matter that this is just as concise as var.)
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revenge of the double-curly [Was: return when desugaring to closures]
On Oct 10, 2008, at 5:44 AM, P T Withington wrote:
On 2008-10-10, at 02:29EDT, Brendan Eich wrote:
An agreement from TC39 this past spring was that function definitions
directly nested in blocks, not specified by ES3, defined block-local
(let) bindings.
Holy smokes. Does that mean we are all going to be writing
function ... () {{
...
}}
to get 'normal' scoping of function body declarations???
No. My words were unclear, sorry. I wrote defined block-local (let)
bindings meaning the functions defined in blocks bound *their own
names* only in the containing block, not in the variable object.
Will `var`
mean `let` in those double-curly bodies?
No, var and let mean the same thing at top level.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revenge of the double-curly [Was: return when desugaring to closures]
P T Withington wrote:
On 2008-10-10, at 02:29EDT, Brendan Eich wrote:
An agreement from TC39 this past sprint was that function definitions
directly nested in blocks, not specified by ES3, defined block-local
(let) bindings.
Holy smokes. Does that mean we are all going to be writing
function ... () {{
...
}}
to get 'normal' scoping of function body declarations???
I don't think so, because at the top level of a function, a function-local
declaration and a block-local declaration are the same thing. Have I
missed something?
Will function definitions be in scope throughout the enclosing block, or
only after and within the definition? E.g.
function f() {
var x = foo;
if (true) {
print(x);// function x() { x(); }, undefined, foo,
// run-time exception, or static error?
x(); // call to x(), run-time exception, or static error?
function x() {
x(); // presumably allowed
}
}
}
I think they should be in scope throughout the block -- for consistency
with the processed for function declarations rule in ES3 section 13,
because being able to put function declarations anywhere in a block may
allow a clearer code layout in some cases, and to allow mutually
recursive functions within a block.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Revenge of the double-curly [Was: return when desugaring to closures]
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 and not what I meant.
Just the function's name is let-bound (block-scoped) for a function
defined directly in a block.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Oct 10, 2008, at 1:25 PM, Waldemar Horwat wrote:
So what should f(5, 0) do?
function f(x, h) {
while (true) {
try {
if (h == 0)
h = function() {break};
Just to repeat something Dave wrote, we don't propose to allow break
in a function where the break is not in a labeled statement, switch,
or loop within that function. Only lambda would support such novelties.
if (x != 0)
f(x-1, h);
else
h();
This will break from the while (true) in the outermost (x = 5)
activation of f.
In Scheme implementations that support it, the analogue is call/ec --
call-with-escape-continuation (weak continuation is another name for
escape continuation) -- where the caller's continuation is the
argument to the procedure passed to call/ec. Escape continuations are
cheaper to implement and simpler to reason about than full call/cc
continuations because of the dynamic error (exception) you get if you
call the escape continuation outside of the dynamic extent of the
current call.
Sorry if this is already known; Dave should wipe my chin as needed
since he is the adult Schemer here and I'm the toddler.
} catch (e) {
alert(caught + e + on + x);
} finally {
alert(f called finally on + x);
}
alert(f looping on + x);
}
alert(f exited on + x);
}
The break itself does not propagate as an exception, just to be clear.
If the statement being broken from is inactive, then an exception will
be thrown from the break evaluation in the function that was assigned
to h. The call to h would have to come after control flow had left the
outermost while (true), via a statement after that loop, or some other
call made via a returned or heap reference (upward funarg).
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Oct 10, 2008, at 3:31 PM, Brendan Eich wrote:
} catch (e) {
alert(caught + e + on + x);
} finally {
alert(f called finally on + x);
}
Skipping the intervening active finally clauses is bad, though -- a
bug in the current wiki rough draft that I should have mentioned. Dave
will post a follow-up soon.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
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 aspect
of the semantics of 'function' that is implicit -- that it cancels out the
scope of break/continue labels -- and it's precisely these implicit elements
of a language feature that break expected equivalences. (They are essentially
unhygienic -- if you push me, I can explain the connection to macros.)
First off, I'm really glad that clean functions are being considered
for ES-Harmony - another step toward hygienic macros!
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;
})()
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?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Strengthening Function.prototype.toString
Hallvord R. M. Steen wrote: On Fri, 26 Sep 2008 19:58:27 +0200, liorean [EMAIL PROTECTED] wrote: 2008/9/26 Erik Arvidsson [EMAIL PROTECTED]: I know that Opera on mobile phones used to return a string representation that did not reflect the original. Yeah. Opera Mobile returned [ECMAScript code] or [ecmascript code]. This was contrary to the ES3 spec (must be parsable as a function definition, IIRC) and also breaks the eval roundtripping by throwing a parse error. Anybody know if those issues have been fixed in more modern versions? No, not consistently across modern versions. It's not likely to be properly fixed for a while yet. The reason is that on many platforms where memory is scarce, not enabling JS decompilation helps reduce memory requirements. Do you keep the original source code of the whole script in memory, or at least somewhere cached? If so, you could store offsets to the function's source within memory/cache in defined functions, and get the function source as a string on demand. It would be slow, but it would fix compatibility, and I hardly think the speed of a relatively little-used feature matters for mobile. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
