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?
Keean. On 11 Feb 2015 07:17, "Geoffrey Irving" <[email protected]> wrote: > On Tue, Feb 10, 2015 at 11:11 PM, Keean Schupke <[email protected]> wrote: > > Does the compiler do anything with curried arguments? A mistake I gave > made > > in the past is to link currying with partial evaluation. They are not the > > sane thing, currying is simply a transform on the function type so the > type > > system sees everything as a unary function. Many languages simply > accumulate > > the arguments in a data structure and only run the function when > complete. > > How aggressive is BitC's partial evaluation? > > 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. > > Geoffrey > > > On 11 Feb 2015 00:41, "Geoffrey Irving" <[email protected]> wrote: > >> > >> Thanks for the detailed explanations, and apologies for the delay in > >> reply! > >> > >> On Sun, Feb 8, 2015 at 6:51 AM, Jonathan S. Shapiro <[email protected]> > >> wrote: > >> > There is another way we could possibly go on the currying issue: > attach > >> > a > >> > Nat to the fn type. This would annotate every arrow with its preferred > >> > arity. So something like: > >> > > >> > define f x y = x + y:int; > >> > f : fn 2 int->int->int > >> > > >> > For output purposes, it's probably clearer to emit that as (int -> > >> > int)-> > >> > int, though that won't work as an input syntax. > >> > >> Output syntax that doesn't work as input syntax seems sketchy. > >> > >> > A function typed this way could still be called in curried fashion, so > >> > it > >> > doesn't have any effect on the programs you can write. The advantage > is > >> > that > >> > we can now express at module and assembly boundaries which calls will > >> > *not* > >> > induce closure formation. In consequence we are now able to perform > >> > efficient calls across module boundaries where previously we didn't > have > >> > enough information to do that. > >> > > >> > Alternatively, we could continue to write function types similarly to > >> > the > >> > way we do now, which in this case would be: > >> > > >> > fn (int, int) -> int > >> > > >> > and simply allow a curried application syntax. I'm inclined to think > >> > that > >> > the important issue here is less about how the type is written than it > >> > is > >> > about whether curried application is supported/enabled. > >> > >> The "fn (int, int) -> int" way seems better, mostly because the int > >> approach doesn't generalize very well to complicated examples. In > >> particular, I routinely fine myself writing functions that look > >> something like > >> > >> f :: a -> b -> c -> d -> e > >> > >> except that it's really > >> > >> f : (a,b) -> c -> d -> e > >> > >> and significant amounts of precomputation happen after (a,b) and c > >> (before d). Thus, you really need an arbitrary number of ints, which > >> doesn't seem like it ends well. > >> > >> Geoffrey > >> _______________________________________________ > >> 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 > > > _______________________________________________ > 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
