Re: n-ary functions rfc

[R. Kent Dybvig <dyb@garbo.cs.indiana.edu>]

Your interface is similar to our lambda* proposal from a few years
back.  I can't find the actual proposal text we submitted to
rrrs-authors, but the interface is written up in the '88 LFP conference
and in a subsequent LASC article (Vol. 3, No. 3).  If someone has an
rrrs-authors archive, the formal proposal should be in there
somewhere.  Essentially, in place of the function and count variables
that follow the "others" key (we used & as a marker), lambda* expects a
"values" variable that will be bound to all remaining values.  These
values may be passed along to another procedure using a special
application syntax (e0 e1 ... en & id), where id is a "values"
variable.

The lambda* proposal included an optional argument interface (the name
lambda* came from the fact that a lambda* expression can have multiple
lambda clauses, each with a different interface and body), and the
whole thing fit in nicely with mutliple return values.  It did not
include a way to directly access the "nth other" argument, but this is
easily added and can be optimized to a direct stack index in many
cases.

I find lambda* preferable since:

 * It guarantees no quadratic copying on recursive procedures written
   using the interface.

 * Correct application to a values variable is a static property, not
   a dynamic one (as with fapply, which sometimes must wait until run
   time to detect that the "other" procedure is a procedure and that it
   works as expected).  There's never any doubt whether or not the
   argument following an & in an application is a values variable.

We considered almost exactly the interface you proposed before we
decided on lambda* for the reasons above.  There is no essential
difference in functionality, though styles of use may be significantly
different.  Also, our equivalent of fapply (the special application
syntax) can be optimized even when the names of primitive operators
aren't tied down, while you must at least tie down the name "fapply".

It seems that you may be guaranteeing constant-time access to "other"
arguments (which lambda* does not guarantee), but that you are allowing
linear overhead for the "other" arguments to fapply.  This would mean
that you cannot write, for example, a linear-time recursive version of
+ using "other" arguments and fapply.  (Of course, a sufficiently
clever compiler could convert the recursive procedure into one that
accessed the other arguments directly, but it can't solve the general
problem.)

Both proposals are more complicated to implement (especially to
implement well) than the current interface, so either way we'd be
making it more difficult to write a simple Scheme interpreter that
supports procedures with arbitrary numbers of arguments.

Kent