>From: Brendan Eich [mailto:[EMAIL PROTECTED] > >The return hazard exists in Smalltalk too. What's different here that >makes you choose differently? Of course, there are more choices than >Tennent-to-the-max lambdas or-else classes-as-sugar. >
The difference is in the foundation language we are starting with. Because of the central role of c-style syntactic control constructs in JavaScript it is unlikely that lambda-based control abstractions will ever be as important in JavaScript as they are in Smalltalk. On the other hand, object literals are core to JavaScript as they are the only mechanism in the current language for declaratively defining a new "kind" of object. Using JavaScript, every significant application probably needs to define new object abstractions but far fewer apps need to define new control abstractions. If it is necessary to make a choice I'm inclined to prioritize enhancing object literals to make them be a better object/class abstraction mechanisms over enhancing lambdas to make them a better control abstraction mechanism. The return hazard is not a significant problem in Smalltalk. This is probably because of the pervasive use of blocks (closures) for all control structures including the simplest if statements. Every Smalltalk programmer learns at the outset that the lexical occurrence of a ^ (ie, "return") anywhere in a method (even with within a nested block) means to return from that method. They generally learn this even before they learn that full semantics of [ ] (ie, lambda). So, there is really never any confusion about whether a ^ was intended to mean return from the block as opposed to return from a method. Occasionally, (actually pretty rarely) situations arise where it would be convenient to explicitly express returning from a block evaluation rather than the method. However, I've never seen a situations where that result couldn't be achieved by restructuring the method so the return case falls off the bottom. Various people have toyed with creating some sort of explicit local block return syntax for Smalltalk (for example ^^) but there are significant complications (since Smalltalk only has block based conditionals the local return would really be a situation of an inner block forcing a return from an outer block) and the need is quite limited. Finally, if restructuring the block doesn't solve the problem, Smalltalk's very flexible exception handling abstractions can probably be used to accomplish a similar result. Don't get me wrong, I like the semantics of break/continue/return that have been proposed for JavaScript lambdas but given our legacy I can see the return hazard being a real problem. And if it is a choice between enhanced object literals and control abstracting lambdas I'd probably go with the object literals. Allen _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
