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
