On Tue, Feb 10, 2015 at 11:30 PM, Keean Schupke <[email protected]> wrote:
> Side effects are interesting. Part of the justification for currying is > that it makes no change in program output, however side effects break this > assumption. Does this mean we should have side effect control (monadic > effects) if we have currying? > I'm not sure that I'd describe this as a justification. I think, rather, that I'd characterize it as a non-objection. It isn't the currying that alters the side effect behavior. It's the partial application. Given def f x y = someGlobal := x + y // arity 2 def g = f 1 // partial application the global doesn't get modified unless g is called. In my view that's not a change to the output. That outcome would be equally true if we required the programmer to introduce a lambda for arity matching purposes. I think it's laziness rather than curried application that alters the mutation behavior here. BitC is an eager evaluation language. I haven't drunk the monads Kool-Aid. I don't have any deep objection to them, but monads do not seem to compose well, and the interaction between monads and concurrency seems problematic. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
