[bitc-dev] Variable Arity Functions?

[Jonathan S. Shapiro]

On Wed, 2006-02-15 at 12:58 -0800, Greg Buchholz wrote:
>     Will BitC have variable arity functions?  If so, how does it work
> with the static type system?

We do not plan to support variable arity procedures for the forseeable
future, because Oleg's trick (which is clever, and we had also spotted
it) doesn't interact well with unboxed argument types that are passed by
value (issue: drives a need for polyinstantiation of the receiving
function).

The following is just to explain what we did consider for archival
purposes:

Depending on the rule for argument consing at the apply site, there is a
straightforward way to handle variadic arguments. Consider an
application:

	(a b c ... y z)

at one point, we had in mind that the rule would be "pair consing" --
that is, that an application of the form above would be interpreted as

	(a (pair b (pair c ( ... (pair y z)))))

Note that this has the effect of matching the C calling convention's
representation on the stack (which was important to us) while resolving
what to do with the "extra" arguments. It also satisfies type checking
pretty easily, but it creates a problem:

Given a procedure

	(define (f x y:'a) ...)

we are left with the problem that there is no useful way to actually
pattern match the last argument. Either the type doesn't matter
(therefore remains an alpha type) or the type is actually interpreted by
the procedure f (therefore gets assigned some concrete type). In order
to really deal with variadic procedures, you really do need to introduce
something like type classes,

Type classes are coming in BitC, and at that point we will revisit
pair-consing (it's a compatible change), but for the moment we aren't
supporting variadic functions.

An additional issue was the need for functions of arity zero. If all
functions are required to take the form

	(fn 'a 'b)

then it is difficult to express the difference between a function
accepting no arguments and a function taking a single unit argument.
This makes cross-linkage to C mildly awkward, and it is why our current
function types have multiple arguments.

Finally, note that variadic arguments lose an awful lot of their utility
when they are unboxed. At that point you actually need to multiply
instantiate the receiving procedure, and a lot of the value of them
disappears.

This is another thing that we need to revisit at some point.

In any case, variadic functions aren't real high on our priority list at
the moment.

>   Here's Oleg Kiselyov's partial solution to
> variadic functions in Haskell using type classes...
> 
>     http://okmij.org/ftp/Haskell/vararg-fn.lhs 


shap