Thank you for the explanations. Block lambda syntax with pipes makes more sense to me now. Given that most of the stuff I do is asynchronous though, I personally would prioritize the semantics this way:
1. Short function syntax with lexical this. 4. Block lambdas with TCP return. Thanks again, kevin On Thu, Mar 8, 2012 at 8:43 AM, Herby Vojčík <[email protected]> wrote: > > > Russell Leggett wrote: > >> Its mostly about being able to make control abstractions - being able to >> make your own loops, conditionals, DSLs - and while you can get close >> with anonymous functions, you'll never get there, because someone will >> want to use 'return' or 'break' or 'throw' and the behavior is all >> screwed up (as we all know). >> >> OTH - if you call a TCO obeying block asynchronously and it calls >> return, what happens? Does it throw an error? Is there a way to make >> that blow up early (maybe not statically, but as part of passing the >> block to the function in the first place?) If not, I fear you may add >> > You don't know if it does a bad thing, until you let it run. > Alternatively, you may want to disallow any and all async lambda blocks. > But from what was presented on the list, async lambda blocks are pefectly > ok until they do the bad thing - only then the error occurs. > > Which is ok, we are in dynamic language, after all. > > Herby > > more confusion than any gain you would get with TCP. >> >> - Russ >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
