Re: [Caml-list] currying...

[qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)]

Tue, 06 Mar 2001 12:14:35 -0800, Chris Hecker <checker@d6.com> pisze:

> 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.

There is no such concept. The same function can have different physical
arity depending on how it was compiled - it doesn't correspond
to anything meaningful in the source. Functions present the same
interface no matter what their physical arity is. From the C level too.

A library which has different behavior depending on the physical
arity of functions it works on is broken. The programmer has no
control how functions are compiled - it's the compiler's business.

> >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,

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.

Since currying is so common and there is so much performance gain in
treating it specially, OCaml does the trouble of applying multiple
arguments at once when it can. This requires a more complex calling
protocol, but is worth the effort.

> unless caml does some really stoked partial evaluation analysis.

I'm not sure what you mean.

> 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.

It happens under the cover. From OCaml's point of view you can treat
is a function which returns a function which returns a function etc.
- 10 times. Or a curried 10-argument function. The point of split
is an implementation detail. It has no effect on the semantics.

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?

I understood that you want to use the distinction to decide to which
C type an OCaml type corresponds. This is broken. An OCaml type of a
binary function, and of an unary function returning an unary function,
is the same.

> 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.

Indeed you allocate a new object when you partially apply a function.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

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