On Mon, Dec 8, 2008 at 4:01 AM, Yuh-Ruey Chen <[EMAIL PROTECTED]> wrote: > Breton Slivka wrote: >> On Sat, Dec 6, 2008 at 9:57 AM, Michael Day <[EMAIL PROTECTED]> wrote: >> >> > (1) Expression lambdas: lambdas whose body is an expression. >> > >> > var x = lambda(y, z) y + z >> > >> > Solves the problem with completion leakage, solves the nested >> > return/break/continue issue. However, quite limited in usage, and makes it >> > difficult to use lambdas to replace functions as they can't contain loop >> > statements. (Hello, recursion! :) >> >> [snip] >> >> 2) It would be really nice to have a callable value that was >> garaunteed not to have side effects. a lambda with an expression body >> might not be that. Nevertheless, this would enable a parallelized >> array "map" function that's safe to use. In the absence of "real" >> multithreading, this kind of parallelism would be a boon for >> applications like 3d games, or image processing. >> > > This little comment got lost in the recent deluge of emails, but I too > would really like some mechanism to avoid or see if a function causes > side effects (and not just mutability).
Without a static type system, there's very little you can do. For example, let's say you wanted a guarantee that a call to some function F doesn't mutate any variables. A simple analysis can determine (conservatively) that F's own code doesn't perform any assignments, but the problem is that you also have to prove the same property for the entire possible call tree rooted at F. So, if F is passed a function and (potentially) calls it, that function has to be proven pure, as well. Sure, you could abandon the proof requirement and turn it into an assertion, so that if F is annotated as "mutation-free" and if, at runtime, it tries to perform an assignment, an exception is thrown. But this doesn't work so well for other computational effects. Throwing an exception itself is an effect, and it would be pointless to throw an exception when your code illegally attempts... to throw an exception. Non-termination is an effect, and it's notoriously immune to runtime checks. I/O effects are possibly the most interesting from a practical perspective, but they're outside the scope of the ES standard. -Jon _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
