Browse thread
[Caml-list] currying...
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Chris Hecker <checker@d...> |
| Subject: | Re: [Caml-list] currying... |
>> Now my question is, is there any way to introspect to get at the >> arity information? >You shouldn't need it. It's an implementation detail and doesn't have >to have any meaning. It should never be used to drive the semantics - >code should behave in the same way no matter how a function is built >internally. But that's not true if I'm trying to proxy a caml function with a c function. I need to know where the "return value" starts. So yes, on the caml side it's an implementation detail, but on the C side it's important (since it's hooking into the implementation). >AFAIK this internal "uncurrying" is limited to a constant (up to 5 >arguments or something). Above that functions are really implemented >as functions returning functions, in groups of 5 arguments. That can't be true at the lowest level, unless caml does some really stoked partial evaluation analysis. If I write a function that takes 10 parms and uses them in a nonlinear way then I don't think you can factor it into 2 5-parm functions. Unless you're saying it just substitutes them into the function, but then it would have to build a whole new function every time your partially applied. Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr