Lambda the Ultimate

The exception would be #:start style keyword arguments, which I believe aren't first class in Scheme.

IIRC, CL can apply keyword arguments as well.

So we hope + is defined (define (+ x . xs) (foldl x %primop+/2 xs) or similarly.

'a -> 'b -> 'c ; curried
'a -> 'b -> ('c) ; alternate writing of 'a 'b -> 'c


You put parentheses around 'c to change the meaning of the arrows?

He described this proposal on the BitC mailing list back in March if you're interested. The general idea is that the bracketing indicates where a closure allocation occurs.

Is the post you linked to supposed to explain the syntax here?

Yes, he shows an example or two of this bracketing notation.

# let multiply x y = x * y;;
val multiply: int -> int -> int = // correct, and expected
# let multiply2 x = (fun y -> x * y);;
val multiply2: int -> (int -> int) = // correct, but undesired


I assume you mean this (mailing list version), but this doesn't look the same as what's above (LtU version). The mailing list version seems to suggest that we greedily group arrows together into the largest possible atomic N-ary function type, using parens to indicate where first order functions are passed around. The LtU version doesn't follow that pattern, AFAICT.

This was more or less just a "casual example". We might restrict our "special" calling conventions to functions with type declarations, as above.

Or we might allow the function definition itself to be written as follows without a type declaration:

stdcall plus x * y = x + y

This would allow the type inference mechanism to do its magic on the argument and return types, while still specifying the calling convention.

BTW, "stdcall" is meant as the Windows API calling convention (a hybrid of the C/Pascal calling conventions), not some abstract concept of "the standard calling convention."

Perhaps better examples would have been:

fastcall plus x * y = x + y
pascal minus x * y = x - y

To address a comment from jcowan, we have this lovely parametric polymorphism that allows us, among other things, to write, name, debug and maintain one type parametrized function definition instead of many. While naming seems insignificant, it's a major boon to the API riddled brains of we mere mortals :-)

So why not for function calling conventions? NOTE: For now, let's put aside a few of the "typed-scheme" papers describing typing strategies for variable arity functions, like map or zip, in cases such as:

x = map odd? [1,2,3]
y = map (+) [1,2,3] [2,3,4]
a = zip [1,2,3] [2,3,4] [3,4,5]
b = zip [1,2,3] [2,3,4]

Let's skip these simple arity issues altogether for now, and instead focus on calling conventions - whether de facto machine standards or language level, such as "all standard functions are of one argument" vs. "in addition we also support functions of complex CL style opt, rest and key lambda lists", just for examples.

So, for a language that is intentionally "promiscuous" with regard to (externally linkable libraries of) functions with many different calling conventions - it would be *very* nice to have a "parametric parameter" over the calling convention(s) of higher order functions.

I imagine that this might require:

(1) some auto-generation of "call-wrappers" around some actual function parameters of "non-standard" calling conventions (with some loss of performance) or ...

(2) better still, some compilation strategy akin to C# and friends' generation and compilation of separate code of generic functions for application to arguments of static types, allowing for processing of "unboxed" values that may not fit withing a machine word, etc.

This compilation strategy applied to functions of various calling conventions might increase code size, but in principle at least, yield much better performance than generating "function call wrappers" for a wide variety of function calling conventions.

If you have a theory for doing parametric polymorphism on calling conventions (in the sense I note, which is quite generally applicable to any language that has containers of some sort), then by all means make use of it. I don't know of any such theory, though.

It sounds like the problems stem from the combination of pair-consing and tupled argument calling convention. I'm not sure what the rationale for pair-consing is, but by eliminating of that, tupled arguments should map nicely to the native calling convention.

Furthermore, tuples provide the necessary heap-allocating explicit partial application support you're seeking.

If you want to optimize multiple argument functions, or make arity meaningful for purposes of interoperability, then both tupling and currying as a means for expressing multiple arguments induce their own set of problems, at least in combination with polymorphism.

If you prefer currying, and thus define the arity to be the number of arrows in the type, then functions that are polymorphic in their codomain cause a problem, e.g. forall a. T -> a. Instantiation with an arrow type "raises" the arity.

If you prefer tupling, and thus define the arity to be the arity of the tuple left of the arrow, then functions that are polymorphic in their domain cause a problem, e.g. forall a. a -> T. Instantiation with a tuple type "raises" the arity.

As shap was already saying, the only way to solve this statically is by introducing n-ary function types as a separate notion, so that T,U -> V is different from T -> U -> V as well as T * U -> V.

Otherwise, you will either need monomorphisation (i.e., whole program compilation or jitting), or some runtime arity conversion. Most FPL implementations go for the latter, in various forms.

PS: Not sure why you are suggesting that tupling is more powerful. Both approaches are equivalent in expressive power. The main question is what your implementation and your syntax optimizes for. (You can even optimize for both, but then things can really get hairy.)

Thanks for the clarification!

Here's a link the SPJ article to which I referred above.

Making a Fast Curry: Push/enter vs eval/apply for Higher-Order Languages

I suppose implementation concerns drive my preference for using tuples to express arity. For a function whose argument syntactically destructures a tuple, one can generate both a "direct call" taking arguments on the stack as well as a second tiny "stub call" that takes a reference to a tuple. The stub unpacks the tuple elements and then calls the "direct call". In a simple implementation, HOFs are just passed the "stub call" taking a tuple reference.

In the case of a function that takes a non-destructured tuple type argument, we need only generate a single function taking a reference to the tuple actual argument.

Favoring tuples and requiring explicit syntax for partial application, if I'm thinking straight, is less expressive than using curried functions. If three-arg-fun is curried, a call such as map three-arg-fun [1,2,3,4] will nicely return a list of functions.

A tuple taking version of three-arg-fun in the above call would just generate a type error instead, and require some syntax like map (\x -> three-arg-fun(x, ...)) [1,2,3,4] to accomplish the same thing.

map three-arg-fun [(1,'a',1.0), (4,'b',6.0)]

That only works for tuples (assuming the obvious types).

and I'd wager that this flip-side "apply-like function application behavior to tuple-grouped arguments" is of greater general programming utility than the automagical partial application of curried functions.

But maybe that's just an issue of individual programming style, targeted application domain or what have you.

But at least in a dynamically typed language, it's not hard to work around it:
map (apply curried-three-arg-fun) [(1, 'a', 1.0), (4, 'b', 6.0)]

If functions are untyped and curried by default, this form of apply is trivial. Just fold the original function over the list (or tuple) of arguments, until either you've used them all or you get an error ("attempt to call a non-function" or something like that).