Re: Dataflow concurrency instead of generators

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 performance cost than many people believe.)

Re: Dataflow concurrency instead of generators

Brendan Eich wrote: > On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote: > >> Bear in mind, though, that adding message passing significantly >> increases the expressiveness of the language, so we should take that >> into account when comparing the complexity of (lambdas + generators) >> with

Re: Dataflow concurrency instead of generators

On May 16, 2009, at 5:50 PM, David-Sarah Hopwood wrote: But you are right that dataflow concurrency is probably not sufficient on its own if we want to make Harmony a practical concurrent language. That is not a goal at this point, and TC39 wouldn't hold the "H"- release for it. Bear in m

Re: Dataflow concurrency instead of generators

Jason Orendorff wrote: > On Thu, May 14, 2009 at 7:35 PM, David-Sarah Hopwood > wrote: >>> For instance, suppose that you have dataflow concurrency, as supported >>> by Oz and by recent dataflow extensions for Ruby, Python, and Scala: >>> >>>

Re: The Anthropic Side Channel (was: How would shallow generators compose with lambda?)

On Fri, May 15, 2009 at 2:26 PM, Brendan Eich wrote: > [...] but plain old iloop DOS prevention as practiced in browsers > does *not* reload the page. And the browser APIs are full of  ways to detect > that finallys didn't run, through effects overt and covert. > [...] > Just consider iloop DOS pr