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?
Keean. 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
