On 11 February 2015 at 18:30, 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? > Excellent question. There's an assumption that all of a defined function's latent effects appear on the final arrow. In my own work I've had to ensure that this is preserved in the presence of (possibly partial) inlining. I am unsure if algebraic effects are a great way to handle this, but it's hard to know without looking at the formal semantics. On 11 Feb 2015 07:17, "Geoffrey Irving" <[email protected]> wrote: > >> Partial-evaluation-the-compiler-optimization is certainly a different >> thing, but currying does mean possible partial evaluation in all >> curried languages. For example, the following two definitions make >> very different beasts in ocaml *before* optimization: >> >> let f x y = g x + h y >> >> let f x = let gx = g x in fun y => gx + h y >> >> Occasionally the compiler will be able to hoist the first into the >> second, but I believe it's a requirement of bitc that the performance >> semantics are sensible without worrying about optimization. Also, g x >> could have side effects. >> > Also we may want to PE on y. Mechanisms that don't preserve that symmetry are problematic. Of course, this sort of programmer-directed factoring and thunking should be fully supported. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
