Re: return when desugaring to closures
On Sep 2, 2008, at 2:16 PM, Lex Spoon wrote: On Sun, Aug 24, 2008 at 3:17 AM, Brendan Eich [EMAIL PROTECTED] wrote: First, let's settle the hash over whether any desugaring without extensions such as return-to-label, reformed lexical scope, tamed this, banished arguments, etc. etc., trumps adding a new binding form, to wit: let as block scoped var. With no extensions, it is true, return would end up returning from a different method under the proposed rewrite. Likewise, this and arguments would cause trouble. Sorry for the very tardy reply. You make good points in the abstract, and the messy language-specific details of existing semantics for functions not being clean enough deserves a better response than just don't desugar. I stand by don't desugar let to functions as-is. I'm also pretty certain don't add more modes or subsets to try to fix existing forms is sound, since versionitis does not help us either keep the spec simple or specify the backward-compatible semantics in the full language. So, to avoid trouble, we've been thinking of new forms including a better function, call it lambda, that has none of the compatibility baggage. I say we but really Dave Herman deserves credit for championing this. A lambda form has been a topic now and then for a while, on this list and in committee, and sometimes only as syntactic sugar (which would miss the opportunity for semantic reform) -- yet without it getting the breathing room it needs. Dave is working now in the http://wiki.ecmascript.org/doku.php?id=strawman:strawman space on the wiki. Don't throw stones, this is not in the harmony: namespace for good reason. Constructive comments welcome. And I still owe the list a story on wiki access that keeps Ecma happy and doesn't throw open the edit wars doors. Among the new strawman pages, the following are relevant and (I hope) helpful: http://wiki.ecmascript.org/doku.php?id=strawman:lambdas http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label Possibly break and continue would, depending on what their precise semantics are. JS has break from labeled statement, and continue to labeled loop bottom, a la Java. These look trouble-free to me. Let me know if you see a hard case. Thanks, /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Thu, Oct 9, 2008 at 5:31 PM, Brendan Eich [EMAIL PROTECTED] wrote:
JS has break from labeled statement, and continue to labeled loop bottom, a
la Java. These look trouble-free to me. Let me know if you see a hard case.
Thanks,
My question was whether the semantics of break and continue would support
the following:
while(true) {
(function() {
if (--x == 0) break;
})();
}
I honestly don't know, but it shouldn't cause any real trouble to allow it.
The implementation would be analogous to that for labeled return. For
example, if the appropriate while loop is no longer on the stack, the
break would turn into an exception.
As my usual disclaimer, I am not closely following the different ES trends
including Harmony. I'm only commenting about what could possibly make the
language more consistent and orthogonal.
-Lex
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Oct 9, 2008, at 3:05 PM, Lex Spoon wrote:
On Thu, Oct 9, 2008 at 5:31 PM, Brendan Eich [EMAIL PROTECTED]
wrote: JS has break from labeled statement, and continue to labeled
loop bottom, a la Java. These look trouble-free to me. Let me know
if you see a hard case. Thanks,
My question was whether the semantics of break and continue would
support the following:
while(true) {
(function() {
if (--x == 0) break;
})();
}
That's currently a specified error (possibly at runtime; chapter 16 of
ES3 allows it to be at compile time).
So a future edition could allow it, probably without opt-in
versioning. Our compatibility model does not guarantee exceptions,
since it allows contemporaneous extensions that remove those
exceptions (see ES3 chapter 16 again, second bulleted list, first
bullet -- these lists need their own sub-sections and numbers!).
I honestly don't know, but it shouldn't cause any real trouble to
allow it. The implementation would be analogous to that for labeled
return.
Right, and break to label outside the function's body, but lexically
in scope, would be completely analogous (or just the same ;-)):
L: while (true) {
(function () {
... // stuff possibly including a loop or switch that brackets
the next line
if (--x == 0) break L;
...
})();
}
For example, if the appropriate while loop is no longer on the
stack, the break would turn into an exception.
Yes, this new runtime exception is the price of admission.
The exception seems to a major source of grief in the Java BGGA
closures controversy, or at least it did when I last looked. But it
comes up with escape continuations in Scheme, and it is inevitable if
we want these kinds of program equivalences.
I'm interested in the reactions of others on the list to such return/
break/continue from already-deactivated statement/frame exceptions.
They could be caught and handled, of course. Feature and bug, dessert
topping and floor wax ;-).
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Oct 9, 2008, at 4:28 PM, David Herman wrote:
How would people feel about the declaration form being 'define'
instead of lambda? As in:
define const(x) {
lambda(y) x
}
Maybe I'm just accustomed to Scheme, but it looks awkward to me for
the declaration form to be called lambda. Dylan also used 'define'.
For named functions, it's less cryptic, it has clearer connotations.
For anonymous functions, e.g.:
(define (x) {...})(x)
or
return foo(define (y) {...}, z);
your mileage *will* vary, but it seems worse by a hair to me. But I'm
used to lambda as a term of art.
The obscurity of lambda helps it avoid collisions (we have ways of
unreserving keywords in property-name contexts, but these do not work
for formal parameters and variables named define, which seem
likelier at a guess than lambda -- spidering the web could help
confirm this guess).
The obscurity also arguably partners lambda better with function.
Setting up define as a cleaner function seems to switch domains of
discourse. Concretely, we have in ES3.1 Object.defineProperty and
similarly named functions. These define APIs were prefigured by
Object.prototype._defineGetter__, etc.. This sense of define has
meant bind property name to value or getter/setter.
On the other side, Python, E, etc. use def. But we would be verbose
like Scheme and Dylan. So define vs. lambda.
End of my bike-shedding ruminations.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
Sorry, I was unclear. I meant 'lambda' for the expression form and 'define' for
the definition form.
Dave
- Original Message -
From: Brendan Eich [EMAIL PROTECTED]
To: David Herman [EMAIL PROTECTED]
Cc: Peter Michaux [EMAIL PROTECTED], es3 x-discuss [EMAIL PROTECTED],
es-discuss@mozilla.org
Sent: Thursday, October 9, 2008 9:12:26 PM GMT -05:00 US/Canada Eastern
Subject: Re: return when desugaring to closures
On Oct 9, 2008, at 4:28 PM, David Herman wrote:
How would people feel about the declaration form being 'define'
instead of lambda? As in:
define const(x) {
lambda(y) x
}
Maybe I'm just accustomed to Scheme, but it looks awkward to me for
the declaration form to be called lambda. Dylan also used 'define'.
For named functions, it's less cryptic, it has clearer connotations.
For anonymous functions, e.g.:
(define (x) {...})(x)
or
return foo(define (y) {...}, z);
your mileage *will* vary, but it seems worse by a hair to me. But I'm
used to lambda as a term of art.
The obscurity of lambda helps it avoid collisions (we have ways of
unreserving keywords in property-name contexts, but these do not work
for formal parameters and variables named define, which seem
likelier at a guess than lambda -- spidering the web could help
confirm this guess).
The obscurity also arguably partners lambda better with function.
Setting up define as a cleaner function seems to switch domains of
discourse. Concretely, we have in ES3.1 Object.defineProperty and
similarly named functions. These define APIs were prefigured by
Object.prototype._defineGetter__, etc.. This sense of define has
meant bind property name to value or getter/setter.
On the other side, Python, E, etc. use def. But we would be verbose
like Scheme and Dylan. So define vs. lambda.
End of my bike-shedding ruminations.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On Oct 9, 2008, at 6:44 PM, David Herman wrote: Sorry, I was unclear. No, my fault for missing declaration form. I meant 'lambda' for the expression form and 'define' for the definition form. Do keywords cost more than concepts? If people think define name(x) x and lambda (x) x are different beasts, then different names win. If people think of lambdas (what else to call them? not functions) as being named or not when used as expressions, and named when declarations (parallel to the existing function forms are in ES3), but being different (albeit similar; cleaned-up) function-like beasts, then one name for the three forms that parallel the ES3 function forms seems better. It's hard to argue about from first principles outside of the specifics of ES3 and modern JS implementations and teaching. The specific JS books I know talk about functions having several forms, so it seems better to me to keep lambda parallel. I see the appeal of define for the declaration (definition, rather) form, though. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
