Dataflow concurrency instead of generators
brendan at mozilla.com
Sat May 16 21:45:39 PDT 2009
On May 16, 2009, at 9:29 PM, David-Sarah Hopwood wrote:
> (Implementation complexity and performance are also important, but
> personally I consider them to be lower priorities than safety and
> expressiveness -- especially since safety often has a lower
> cost than many people believe.)
I'm still looking for evidence other than your certainty re: the last
dispute about semantic cleanliness (by your lights) vs. performance:
When we see SFX (Nitro, heh), V8, and TraceMonkey on board then I will
be convinced. Until then hand-waves and generalizations don't really
> Remember, I started this thread by arguing against (lambdas +
> precisely because that combination caused a safety problem.
It's already the case that finallys may not run, whether or not you
add generators and lambdas.
> So we
> have no disagreement on the principle that unsafe combinations of
> features should be avoided even if they would be highly expressive.
> We disagree on whether the identified problem is best avoided by
> ditching lambdas (and replacing the lost functionality with what?)
Waldemar argued for reforming function. If we add rest and default
parameters then there isn't much to do, other than try to force
Tennent into a language it doesn't fit.
> Note that the fact that a language supports highly expressive
> features doesn't mean that any particular program must or should
> use those features.
Yeah, yeah... There are many bodies, fingers and toes already chalked
up to this kind of thinking applied elsewhere (C++).
Besides the honey traps, implementation barriers should not be raised
too high. One good reason to avoid this is to achieve interoperation
among many competing browser vendors. To pick on C++ again, it took
too long to get semi-interoperable implementations due in part to the
complexity inherent in all that expressiveness. There are other
languages from which to learn the same cautionary tale.
> However, programming in a highly expressive language
> that supports multiple programming paradigms (but designed with
> considerable attention to maintaining safety properties) makes it
> just isn't cut out to be that language, but I'd like to at least
> have a stab at making it closer.
On this very general point, we agree.
More information about the es-discuss