On Aug 21, 2008, at 2:29 PM, Lex Spoon wrote: > (- es-discuss, which I'm not on)
Why not join? es3.x-discuss is not the place if its purpose is focused discussion about the ES3.1 spec work that's before TC39. This kind of thread belongs in es-discuss, so I'm cross-posting with reply- to set. > On Thu, Aug 21, 2008 at 2:45 PM, <[EMAIL PROTECTED]> wrote: >> On Thu, Aug 21, 2008 at 11:24 AM, Mark S. Miller >> <[EMAIL PROTECTED]> wrote: >>> When it doesn't work, it doesn't work. But when it does work, it's >>> highly worthwhile because it's the closest thing we've got to proper >>> lambda abstraction. >> >> ... and to *my* mind, the benefit of (defining the semantics as) >> desugaring to something well-understood (be it proper lambda >> abstraction or otherwise) is that the primitives of the language are >> now more amenable to formal -- or even semi-formal -- reasoning. > > I would add that there is a long history of variable-definition forms > in PLs that look okay at first but turn out to be bad to program with. > JavaScript's var is just one example. The dynamically bound > variables of Lisp haunted that community for decades. It's uncanny how people keep reinventing Lisp, compleat with dynamic scope. In the nineties, Perl, TCL, and JS all flirted with disaster. The maddening mix of dynamic scope (the hopeless global top-level, with, eval) and lexical scope (with warts like hoisting of vars, along with better-motivated let rec bindings of function definitions) in JS is something I believe the committee should address in Harmony. Doing it compatibly and compositionally will require new forms that opt into true lexical scope. > This problem is especially disturbing because the problems are so > subtle. Once you've convinced yourself that JavaScript's var is > problematic, it's really hard to summarize the argument concisely. > You can show coding examples where programmers get surprised, but many > will respond and simply say don't do that. You can show > term-rewriting rules that should be but aren't equivalences, but > people's eyes glaze over. I can give a rule of thumb, though, for > avoiding these problems to begin with: go with an existing design. > The desugaring of lets into functions and function calls is not some > obscure new invention, but a common one that has stood the test of > time well. No, it hasn't, because you are talking about JS functions, with | this|, arguments, and so on. I don't know why you changed the argument from decrying var binding to treating JS functions as if they were well-behaved lambda expresions or Scheme procedures. > Also, Brendan, please be aware that the languages I listed are not > some obscure collection of random languages. Hey, did I just fall off the turnip truck? Please assume knowledge of the languages you cite, and deal with the point I made in reply: these do not all bear on any evolution of JS that's backward-compatible and not a Frankenstein's monster language (like Objective C, say). > I fully agree that > different languages aren't necessarily comparable to each other. > However, those I named have the same semantics as JavaScript for the > relevant features: nested functions, function calls, parameters, and > the proposed let-bound variables. No, they do not. Common Lisp, Scala, and Smalltalk do not have the same semantics in detail as JS does with respect to functions, calls, parameters, and any let proposal I've seen or implemented. If you look from 100,000 feet, you could say they're all similar, but they are not the same. Just one example: Smalltalk has block objects, quoted code you can activate by sending a message. You could say that's just like a function, except where it is quite different (http://c2.com/cgi/wiki?SmalltalkBlockReturn). Never mind JS functions having variable arity, unbound |this| parameterized by call expression, arguments object, etc. Arguing by authority is a fallacy. We need specific solutions from other languages that could compatibly fit into JS as extensions. I welcome such specific proposals. The committee has before it the let- as-better-var proposal, which was favorably received by many in Oslo. > The approach you are saying won't > work, is in fact the chosen and working solution for other languages > that have gone this route. My understanding is that programmers using > these languages have been happy with the arrangement. I don't know what you mean by "The approach". Can you be concrete? /be _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
