On May 6, 2011, at 11:22 PM, Peter Michaux wrote: > On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont <[email protected]> > wrote: > >> I don't want to get too deep into matters of taste, but I do think the >> current syntax is annoyingly verbose for passing lambdas as arguments in >> other functions. The fact that it's so verbose ends up hurting readability >> when the function itself is short. > > I think that this is what compilers and projects like coffeescript are > for. In my opinion, JavaScript itself doesn't need this new syntax.
You're free to keep writing eight characters all over the place :-|. If you don't like reading a shorter function syntax (# has been proposed as well as ->, and I've combined the two to make #'s meaning compositional with respect to object initialisers for records and array initialisers for tuples), then shun the offending code by not reading it. > I think improving JavaScript as a compilation target is a good goal. > For example, a real "lambda" with guaranteed proper tail calls, no > "arguments", no need for "return", That's what I'm proposing, ignoring control effects. By "real 'lambda'" you must also mean new control effects, with novel runtime exceptions, e.g., for return in a lambda attempting to return out of an inactive outer function. We've already decided several times (on this list, even) not to do that kind of lambda. IIRC Maciej's post dealt the death blow: http://www.mail-archive.com/[email protected]/msg01533.html But why in the world are you favoring new and definitely more confusing runtime semantics along with lambda syntax, while objecting to shorter function syntax that avoids ten or 12 of 14 letters? > etc would make is possible to > compile Scheme to JavaScript without using something inefficient like > trampolines. It would also open up recursive programming options in > plain JavaScript so it would be win-win. Yes, and we could add call/cc to make (some) compiler writers even happier. But users would shoot off all their toes with this footgun, and some implementors would be hard-pressed to support it. The point is *not * to do any one change that maximizes benefits to some parties while harming others. Again, I claim you are not harmed by shorthands. Read them or reject them, don't use them. JS has many ways to say things, it is already multi-paradigm in shallow and deep ways. /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
