I have an idea that closures can (always?) be stack allocated, a key idea is that of move semantics for return values. You can reserve the space for the closure in the callers stack and pass this in by reference to the function that would create the closure. Maybe this is something well known, i'm not sure?
In regards to currying, without partial application, all currying does is introduce inefficiency as you have to accumulate all the arguments somewhere before calling the function. I think in the non-partial application case un-curried functions make more sense. The problem with partial evaluation is, consider: f x y = (g x) + (h y) What if 'g' throws a division by zero error, or runs out of memory and throws a runtime exception. In that case with partial evaluation, the program will fail as soon as 'f' is applied to its first argument. In the extreme case where the computation is abandoned before the second argument is applied this could be the difference between the program crashing, and running with no errors. So its not Laziness thats the only problem, partial evaluation is too, and without partial evaluation, what is the point of currying? All it does is make things less efficient. Keean. On 11 February 2015 at 16:00, Jonathan S. Shapiro <[email protected]> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
