On Thu, Feb 5, 2015 at 10:59 PM, Geoffrey Irving <[email protected]> wrote:
> What's the current status of currying vs. multiple argument functions > in bitc, in terms of syntax and implementation? I remember this being > discussed at some point, but not the conclusions. > Geoffrey: In BitC v0, I ended up going with multiple argument functions. I was concerned about cross-language calling compatibility, and particularly about registerization. I was also concerned about the fact that curried-style functions tend to induce heap allocation (at least in non-optimized implementations), and we were working hard at that time to design a language where you weren't likely to find yourself allocating unintentionally. I still think the allocation issue is important, but I now think I understand how to deal with that in the cases where the function turns out to be called with its "naturally intended" number of parameters. The problem originally was that v -> x -> y -> z doesn't tell you the naturally intended arity. This makes it a bit challenging to properly registerize calls across module boundaries. F# came up with a nice solution to the calling convention problem: if you call a function having a tuple pattern as it's single parameter, there is a specification that says how the tuplized arguments will get passed. And yes, you guessed it: it's possible to be fully compatible with the native registerization conventions. But it means that the signatures are different: let f : (i : int, j : int) = i f: int * int -> int let g i:int j:int = i g: int -> int -> int F# cannot export curried functions across an assembly boundary, because the CLI type system cannot describe them. More in a bit - I need to go pick up my son from school shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
