Re: [Caml-list] currying...

[Chris Hecker <checker@d6.com>]

>A library which has different behavior depending on the physical
>arity of functions it works on is broken. 

It's not going to have different behavior, and it's not an optimization.  The library has to know because it has to know when to call a C function from another C function and it has to tell caml when to call it from caml.

Say I give a prototype to the library that's int -> int -> int -> int and I expect the library to give me back a closure that thunks to a c function.  Two things (at least) have to go on here:

- the library needs to know whether this is "int (*)(int,int,int)" or "int (*(*)(int))(int)" (or something else) so that it can create a closure to pass back to caml that has the right physical arity so that caml will call it and expect the right return type

- the library also needs to know the above so that it can call the linked c function correctly with the right number of arguments (this is analogous to the cast you have to make in C when you GetProcAddress/dlsym)

Since this is all happening dynamically, I need to be able to deduce the physical arity of the functions at runtime.

> Why? "Uncurrying" anything at all is an optimization. A straightforward
>implementation would just apply arguments one at a time, allocating
>a closure at each step.

Yes, I understand allocating the closure and it appearing like there's a bunch of 1 parm functions, but at some point the _actual_ function that does the work has to be called, so the implementation must know.  The only alternative is real partial evaluation to reduce the actual physical arity (meaning the function is specialized on its partially applied parameters and regenerated as an arity - 1 function), which is just way too complicated for caml or any other production language, I'd assume, so caml must just allocate a bunch of closures until it gets enough to call the original physical function.

> No code should rely on where it is, unless it hides this under its
>cover too and presents a unified interface to the outside. Do you
>really have a case where you can use this fact to enable better
>performance?

Again, it's not performance.  The C side has to know for me to write this library, as I said above.  All this will definitely be hidden, so you'll be able to pass partially applied functions and partially apply the returned functions, so the programmer won't know.  But there'll be a lot of stuff going on underneath to make this work.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr