Bakul Shah  <bakul+usenet@bitblocks.com> wrote:
+---------------
| Rob Warnock wrote:
| > What CL *really* needs here is just a small tweak to REDUCE, to add
| > one additional keyword argument, :MAX-ARITY, that permits REDUCE to
| > use a larger arity than 2 on the intermediate applications of the
| > function being REDUCEd. It might be defined this way:
| 
| No need to complexify its interface as reduce can be implemented
| using a fixed amount of temp space even without TCO...
+---------------

CL:REDUCE's interface is *already* quite complex, with five ANSI-mandated
keyword args already [:KEY :FROM-END :START :END :INITIAL-VALUE]. One more
keyword would hardly be "complexifying" it.

As others have noted, in the case of #'+ if all the compiler would use
is an underlying 2-arg machine instruction (or 2-in/1-out, for RISC),
then :MAX-ARGS doesn't buy you much. But that's just the simplest case.
A :MAX-ARGS keyword might be very useful if either:

1. The compiler knew about & could use some underlying vector arithmetic,
   such as x86 SSE{2,3}; or,

2. The function being REDUCE'd is both *expensive* to call and
   inherently variadic [but with little incremental overhead per
   additional argument]. In that case, operating on "bunches" of
   args at a time could be a real performance boost. A possibly
   worst-case example of this would be if each function call required
   a setup/teardown of a network connection [think SQL database access],
   or allocating/releasing a bunch of slave processors [Google-style
   MAP/REDUCE], etc.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607