Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] currying...
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-06 (20:14)
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

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.


To unsubscribe, mail  Archives: