[bitc-dev] Implications of pair

[Jonathan S. Shapiro]

Two motivations for PAIR replacing TUPLE are varargs compatibility for
external function declarations and for a kind of "poor man's currying".

The proposal currently reflected in the document is that all procedures
(logically) take a single argument, and that applications are
syntactically rewritten as follows:

  (e1 e2)              => (e1 e2)   ; already canonical
  (e1)                 => (e1 ())   ; i.e. unit instance
  (e1 e2 e3            => (e1 (pair e2 e3))
  (e1 e2 e3 ...)       => (e1 (pair e2 (pair e3 ...)))

where the "..." is reduced in right-associative fashion until only one
item remains, resulting in the expected right-reduced nesting of PAIR
forms.

What we lose is a certain degree of regularity in argument processing,
because there is nothing comparable to "tuple of one element" and
because it is no longer the case that all procedures take tuples as
arguments. However, the "all arguments are tuples" thing was really a
consequence of the specification of APPLY. It was never a "feature" in
my mind.

Note that the low-level code emission can exploit the type system to
avoid passing that unit tuple in the case of no arguments.

Also, I like the fact that if function calls are specified this way then
we can explain the type of the CLOSE operation that forms closures:

  close: (fn (fn (pair 'a 'b) 'c) (fn 'b 'c))

this is actually quite nice, and it will help us explain objects when we
get around to specifying DEFOBJECT.